Recent changes and next release
Waldek Hebisch
up Lisp macros and support functions. Build system get a bit
simpler and (at least using sbcl) we have saving in disc space
used for build (build time should be more or less the same as
before). The is also some potential for breakage.
I would like to do next release in February. Optimistically
in two weeks from now, but there is a lot of things that
I hope to add, so there is possibility for delay.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Baker
> I would like to do next release in February. Optimistically
> in two weeks from now, but there is a lot of things that
> I hope to add, so there is possibility for delay.
Would you be interested in including the graph theory code I mentioned
before?
If so I expect to have some changes to both:
graph.spad.pamphlet
scene.spad.pamphlet
For maximum benefit it would require a new version of both of these so
that graphs are drawn better. For instance fixed points will be drawn
as a circular arrow from a vertex back to itself and arrows now stop
short of the vertex in an attempt (not always successfully) to avoid
drawing arrows over the top of labels.
So, if you are interested, let me know when you have a cut-off date
and I will make the latest code available.
Martin
leh...@bayou.uni-linz.ac.at
> Would you be interested in including the graph theory code I mentioned
> before?
at some point I will want to include infinite graphs as well,
see the section CayleyGraph in
https://github.com/cerambyx/fricas
But first there are other things in the queue.
best regards,
Franz
Martin Baker
Would there be any commonality between finite and infinite graphs?
That is are there any functions that can be applied to both and should
be pulled out to a common category?
Martin
PS I'm curious about the stuff in here about 'animals'. I have not
come across that, all I can find on the web is 'lattice animal' which
seems to be related to multi-square dominoes? Are they related to
infinite graphs?
leh...@bayou.uni-linz.ac.at
On Wed, Feb 01, 2012 at 08:46:22AM -0800, Martin Baker wrote:
> Would there be any commonality between finite and infinite graphs?
yes, think of any local property like "neighbours", "distance" etc.
which do not see whether the graph is finite or infinite.
Others, like "spanning tree", "adjacency matrix" etc.
are confined to finite graphs.
So it probably makes sense to separate.
> PS I'm curious about the stuff in here about 'animals'. I have not
> come across that, all I can find on the web is 'lattice animal' which
> seems to be related to multi-square dominoes?
yes, that's the same thing generalized to arbitrary graphs.
The code here is just brute force, but was sufficient for the
simulations I needed some time ago (http://arxiv.org/abs/0712.3135,
http://arxiv.org/abs/0805.0867).
Physicists have put a lot of effort and sophistication
in order to enumerate them on Z^d. The current state is that animals
of size up to 50 something can be enumerated exactly.
> Are they related to infinite graphs?
An animal is a finite connected subgraph containing the root vertex.
It makes sense for any graph, however since the important thing is
the asymptotic number of them, it is not really interesting for finite graphs.
best regards,
Franz
Waldek Hebisch
>
> On Tuesday 31 Jan 2012 17:38:29 Waldek Hebisch wrote:
> > I would like to do next release in February. Optimistically
> > in two weeks from now, but there is a lot of things that
> > I hope to add, so there is possibility for delay.
>
> Waldek,
>
> Would you be interested in including the graph theory code I mentioned
> before?
Yes. I have my own ideas how graph should be done and as you
see Franz Lehner also did work in this direction, so we will
probably be pushing some changes (more about this tomorrow).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Baker
https://github.com/martinbaker/fricas/blob/master/src/algebra/graph.spad.pamphlet
and also the graphics framework here:
https://github.com/martinbaker/fricas/blob/master/src/algebra/scene.spad.pamphlet
The changes to the graph theory depend on the changes to the graphics
framework so it would be quite good if you chose to include both with
FriCAS. At least I would not have to do so many loads before doing any
work!
The changes to the graphics framework affect the user interface, but
only the functions for drawing arrows.
On Wednesday 01 Feb 2012 17:32:52 Waldek Hebisch wrote:
> Yes. I have my own ideas how graph should be done and as you
> see Franz Lehner also did work in this direction, so we will
> probably be pushing some changes (more about this tomorrow).
But I have started to address your earlier concerns:
1) I have renamed Graph category to FiniteGraph (FGRPH). I would like
this to extend a more general Graph (GRPH) category which would
include functions such as 'neighbours' and 'distance' which are common
to both finite and infinite graphs. However, at this stage, I don't
know how infinite graphs would be represented (presumably some
inductively defined data structure). Therefore I don't know how
vertices of the graph would be referred too, in the most general case
(can they still be indexed), so I don't know if the same signature can
be used for 'distance' in the finite and infinite cases. I have
therefore left this Graph (GRPH) category as a possible future
enhancement.
2) I have included Ralfs loop construct patch.
3) I have added definitions for terms like spanning tree and forest to
the documentation. What is currently called spanning tree and forest
is misnamed but I haven’t altered the code yet as I want to make sure
I get agreed definition.
4) I have changed WeightedGraph to allow weights to be assigned to
both verities and arrows (although vertex weights are not yet used).
Martin
Waldek Hebisch
>
> I have updated the graph theory code here:
>
> mphlet
>
> and also the graphics framework here:
>
> mphlet
>
> The changes to the graph theory depend on the changes to the graphics
> framework so it would be quite good if you chose to include both with
> FriCAS. At least I would not have to do so many loads before doing any
> work!
Changes to scene.spad.pamphlet contain a lot of whitespace change,
do you really mean it? Also, did you compare with version that
I commited? Apparently your new version is wiping out a few
spelling corrections that I made (construct vs constuct).
>
> The changes to the graphics framework affect the user interface, but
> only the functions for drawing arrows.
>
> On Wednesday 01 Feb 2012 17:32:52 Waldek Hebisch wrote:
> > Yes. I have my own ideas how graph should be done and as you
> > see Franz Lehner also did work in this direction, so we will
> > probably be pushing some changes (more about this tomorrow).
>
> I have not seen this, did I miss something?
I had to many distractions. Anyway, here are remarks. I think
that we should have a collection of classical algorithms for graphs.
And they should be efficient. I hope that I can quicky code
a few "easy" algorithms: minimal/arbitrary spanning forest,
connected components, strongly connected components,
biconected components, minimal distances, maximal flow.
I have some ideas how to quickly do semi-reasonable isomorphizm
test -- should work fast for large "random" graphs, but
behave poorly on regular graphs, but that while can be done
relatively quickly, almost surely will take too much time for
coming release. Other things like planarity (there is linear
algorithm for this), chromatic number, etc are highly desirable,
but reguire much more effort. All the algorithms should use
array representation of graphs (otherwise there is no hope for
efficient implementation). ATM it is not clear for me if graphs
represented in arrays (we need a bunch of arrays for single graph)
should get their own domain -- we can simply make an algorithm
package which just takes array arguments and converts
graphs to array form in the graph domain. Certainly such
graphs should _not_ have drawing related information
(such information would be pure overhead, with no reasonable
way to update and of limited use because it is practically
impossible to look at very large graph as a whole).
> But I have started to address your earlier concerns:
>
> 1) I have renamed Graph category to FiniteGraph (FGRPH). I would like
> this to extend a more general Graph (GRPH) category which would
> include functions such as 'neighbours' and 'distance' which are common
> to both finite and infinite graphs. However, at this stage, I don't
> know how infinite graphs would be represented (presumably some
> inductively defined data structure). Therefore I don't know how
> vertices of the graph would be referred too, in the most general case
> (can they still be indexed), so I don't know if the same signature can
> be used for 'distance' in the finite and infinite cases. I have
> therefore left this Graph (GRPH) category as a possible future
> enhancement.
I must admit that ATM I would limit effort spent on infinite
graphs. Basically, for infinite graphs for almost any
operations I can imagine sensible representation such that
this operation is impossible to do. As simplest example
consider graphs that have finite degree at some nodes, but
infinite at other nodes and allow retrival of adjacent nodes
only as a Stream. Or worse, graphs where you can not list
neighbours, but can test if an edge is in the edge set.
Note that in the first case (adjacent nodes as a stream)
it may happen that you can not decide if node is in the
graph.
In fact you may have theoretically finite but "practically
almost infinite" graphs: there are so called binary decision
diragrams (and variations) which in some cases allow
to represent huge structures (say of 10^100 nodes) in
much smaller space. They are widely used for finite
automata, but in principle should also work for graphs.
If you try to retrive list of neighbours of a node of such
graph you will overflow available memory, so only way
to work on them is via relational operations.
Now, ATM we do not have infinite graphs, and IHMO it
is pointless trying to anticipate all possiblities,
Murphy say the one of possibilites that you did not
consider will be the important one. Given that Franz
has some code, it makes sense to make some accomodations,
but that code will evolve and only later we will know
what is the right thing to do.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
leh...@bayou.uni-linz.ac.at
On Tue, Feb 07, 2012 at 06:53:43AM -0800, Martin Baker wrote:
> to both finite and infinite graphs. However, at this stage, I don't
> know how infinite graphs would be represented (presumably some
> inductively defined data structure). Therefore I don't know how
> vertices of the graph would be referred too,
infinite trees given by Gray codes, the Young lattice and other
locally finite graphs which can be encoded into finite data.
Functions like 'neighbours' or 'distance' 'edge?' have to be coded for every
graph individually. Counting walks is perhaps the most important application.
At the moment I only used them as a convenient way to pick finite
subgraphs and operate on them. Infinite adjacency matrices (with finite
rows and columns) as two-dimensional Streams could be the next step
when the need arises. But this should go into InfiniteGraphCategory
anyways.
regards,
Franz
Martin Baker
> we can simply make an algorithm
> package which just takes array arguments and converts
> graphs to array form in the graph domain. Certainly such
> graphs should _not_ have drawing related information
> (such information would be pure overhead, with no reasonable
> way to update and of limited use because it is practically
> impossible to look at very large graph as a whole).
I am not quite sure if you mean just the algorithm package should not
have drawing related information or the whole graph code?
I somehow suspect there is a fundamental difference between us here in
what we are trying to achieve. What I want is not just a set of
algorithms but also something that is useful for human users to learn
and experiment with this mathematics.
I don't just mean coordinates for representing in a plane but also
designations/names for vertices and arrows and so on. Regarding the
graphics, I think that people differ on this a lot, some people tend
to think visually and some don't, I personally would not want to work
on graphs without being able to see them.
As a general rule I think it is important to separate out the graphics
stuff as far as possible. I have tried to put the graphics stuff into
the graphics framework: 'scene.spad.pamphlet'. However, in this case,
I have not found a way to separate out these issues completely.
I did consider creating a wrapper domain, which would be external to
the graph code, that would allow annotation and coordinate information
to be associated with a vertex. However, if we want to do this with
arrow information (which I do), then we would have to have a separate
external arrow domain. There might be some benefits to this but its
also quite messy, if we continue to use indexes then they have no
meaning outside the graph and if we specify to objects directly then
there are efficiency issues. If we do all that then, the Rep will be
free of annotation and coordinate information, but the graph code
still needs to know about coordinate information. For example, if we
are taking the product of two graphs, then we can combine the
coordinate of the two operands to generate useful coordinate
information for the product graph as a whole.
So, in the end, I could not separate out the graphical/annotation
information. It was just easier and more efficient to leave this
information in Rep even though it goes against certain principles.
I agree the graphics information becomes less useful as we scale up,
but for me, that is no reason not to include it. In fact a matrix
representation also scales up badly and I can't think of a
representation based on outputForm that would be useful for a human
reader and would scale up well. So how would large graphs actually be
used? As algorithms for other packages?
So is there a fundamental difference between us in principle here?
Should I follow my own approach independently?
Martin
Ralf Hemmecke
> do you really mean it? Also, did you compare with version that
> I commited? Apparently your new version is wiping out a few
> spelling corrections that I made (construct vs constuct).
Martin, I guess, you should learn how to rebase your changes on top of
master before you work on new improvements and before you propose a new
version. At least you should merge with trunk.
I don't know how exactly you have set up your local repository if you
have followed
https://sites.google.com/site/hemmecke/fricas-svn#how-to-work-with
you will have a remote called "upstream". Then
git checkout master
git fetch upstream
git rebase upstream/master
should be enough. Well, you might have to resolve conflicts. Contact me
if you run into troubles.
Instead of git rebase you probably can also do
git merge upstream/master
The output is a little different (not linear anymore), but that is
probably still better than not incorporating the latest changes from
trunk at all.
Ralf
Ralf Hemmecke
> what we are trying to achieve. What I want is not just a set of
> algorithms but also something that is useful for human users to learn
> and experiment with this mathematics.
> I don't just mean coordinates for representing in a plane but also
> designations/names for vertices and arrows and so on. Regarding the
> graphics, I think that people differ on this a lot, some people tend
> to think visually and some don't, I personally would not want to work
> on graphs without being able to see them.
Martin, yes, you might have different views from anyone else, I think
what Waldek is trying to say is "think minimal". And, in fact, SPAD
allows for such a design. A graph is just nodes + edges. I could imagine
a design where one would build the graph on top of two types N and E
which represent a node and an edge, respectively. Depending on what
these types are
Graph(N, E)
would then either be a labelled/unlabelled graph with labelled/unlablled
and weighted/unweighted and directed/undirected edges.
The exports of Graph depend on the exports of N and E. If the graph is
directed, one would export other algorithms than for undirected graphs.
If you want positioning information, you can have that, simply export it
from N and in the Graph code deal with it. But for a "drawable graph", I
would probably rather create DrawableGraph(N, E) which inherits from
Graph(N, E), but expects N to contain (x,y) coordinates.
Martin, I appreciate very much that you experiment with graph code and
invest time to climb to steep ladder of becoming a SPAD expert. We
should have many more people of your kind.
Still, what goes into a FriCAS release should actually be thought of
quite a bit. If the code is in, it has to be maintained and one cannot
easily change the interface without making some people unhappy that rely
on the original interface. Well, for the moment, that's probably not a
big issue, but in the long run, we (as main developers) must think about
a good infrastructure that allow anyone to develop his/her code on a
branch and have others to review the code until it becomes stable enough
to be included into a fricas release.
I'd very much like if we were using git as the main underlying VCS, but
since there is github and git-svn, we can already have such an
infrastructure now. Each person who proposes to include something into
fricas should have a branch that one could fetch and simply say
"configure && make && make install" to be able to see the effects of the
new code.
Ralf
Martin Baker
> Martin, I guess, you should learn how to rebase your changes on top of
> master before you work on new improvements and before you propose a new
> version. At least you should merge with trunk.
>
> I don't know how exactly you have set up your local repository if you
> have followed
> https://sites.google.com/site/hemmecke/fricas-svn#how-to-work-with
> you will have a remote called "upstream". Then
>
> git checkout master
> git fetch upstream
> git rebase upstream/master
>
> should be enough. Well, you might have to resolve conflicts. Contact me
> if you run into troubles.
>
> Instead of git rebase you probably can also do
>
> git merge upstream/master
>
> The output is a little different (not linear anymore), but that is
> probably still better than not incorporating the latest changes from
> trunk at all.
Usually the situation is that I work on the code (in seperate spad
files) and documentation (in pamphlet file). So when I wish to publish
I do the following:
1) cut and paste all the seperate .spad files back into pamphlet file.
2) download the master pamphlet file to my local computer.
3) compare my new pamphlet file with master just downloaded by using
KDiff3 program and resolve any differences.
4) if there have been any changes by Waldek then untangle (using cut
and paste) this back into seperate .spad files.
5) check that they still compile in case there is some interaction
between my and Waldeks changes.
6) upload new pamphlet file to github
Upto now this has worked although it is very tedious. Recently there
was a problem with matrix and scene files and I think this is because
I started to use a program called 'Kile' to edit the pamphlet files
(as it has some help with LaTeX commands). I guess its always going to
be a problem using such a program to edit a file that contains a
mixture of Tex and code.
Martin
Waldek Hebisch
>
> On Tuesday 07 Feb 2012 21:12:03 Waldek Hebisch wrote:
> > we can simply make an algorithm
> > package which just takes array arguments and converts
> > graphs to array form in the graph domain. Certainly such
> > graphs should _not_ have drawing related information
> > (such information would be pure overhead, with no reasonable
> > way to update and of limited use because it is practically
> > impossible to look at very large graph as a whole).
>
> Waldek,
>
> I am not quite sure if you mean just the algorithm package should not
> have drawing related information or the whole graph code?
just the algorithm package
> I somehow suspect there is a fundamental difference between us here in
> what we are trying to achieve. What I want is not just a set of
> algorithms but also something that is useful for human users to learn
> and experiment with this mathematics.
I understand this. As a developor I am mostly interested in
algorithmic aspects, but I appreciate need for other aspects
and actually I am happy that you take care of them.
OK.
> I agree the graphics information becomes less useful as we scale up,
> but for me, that is no reason not to include it. In fact a matrix
> representation also scales up badly and I can't think of a
> representation based on outputForm that would be useful for a human
> reader and would scale up well. So how would large graphs actually be
> used? As algorithms for other packages?
>
> So is there a fundamental difference between us in principle here?
> Should I follow my own approach independently?
I think you misunderstood my message. Of course you need extra
information to have good presentation of graphs. And while it
would be good to separate mathematical information from "graphic"
one, I understand that it was not practical. My points are:
- your package could benefit from algoritms
- I would like algorithms which are not tied to the representation
you use now, because:
+ this representation has efficiency problems
+ I envision other clients of algorithm part
- the two points above put some constaints on domains/packages:
+ it would be wasteful to have two sets of identical algorithms
operating just on different data structures, so your graph domain
must be able to use algorithms package
+ but due to representation differences we can not put algoritns
into your graph domain, so you will have to accomodate
appropriate convertions (including some special handling
to restore/preserve graphic information)
I think this will be clearer when I present some code for
algorithms, then we will have something concrete to look at
and will see if my ideas couse problems to you (and if yes, then
how to resolve them).
BTW: I know that time passes by, and if I have too many distractions
this (adding algorithms) may move past the coming release, but ATM I
still hope that we can make it (with some tiny delay to the release).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Baker
> do you really mean it? Also, did you compare with version that
> I commited? Apparently your new version is wiping out a few
> spelling corrections that I made (construct vs constuct).
https://github.com/martinbaker/fricas/blob/master/src/algebra/scene.spad.pamphlet
In a lot of cases I preferred the whitespace that I originally posted
so I have left multiple spaces in comments where it is intentionally
used for indentation and changed the cases where it is not.
I've restored the correct spelling of 'construct' and confirmed that
there were not any other regression errors.
Thanks for pointing this out.
Martin
Martin Baker
Martin
Martin Baker
it is too late to include it in the next release I will merge it in
afterwards. I just thought I would mention it in case there is still
time.
https://github.com/martinbaker/fricas/blob/master/src/algebra/graph.spad.pamphlet
There is already the ability to construct or coerce a graph from List
Permutation or PermutationGroup but these construct a graph
representing the permutations whereas 'toCayleyGraph' constructs a
true Cayley graph.
Martin
Waldek Hebisch
>
> I have put the correction for this in the usual place:
>
> https://github.com/martinbaker/fricas/blob/master/src/algebra/scene.spad.pamphlet
Commited now.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
> I have added a new function 'toCayleyGraph' to MultifunctionGraph. If
> it is too late to include it in the next release I will merge it in
> afterwards. I just thought I would mention it in case there is still
> time.
>
> https://github.com/martinbaker/fricas/blob/master/src/algebra/graph.spad.pamphlet
>
I plan release next week. I think that last additions will be on
Tuesday. So I am picking updated version.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
> I have added a new function 'toCayleyGraph' to MultifunctionGraph. If
> it is too late to include it in the next release I will merge it in
> afterwards. I just thought I would mention it in case there is still
> time.
>
> https://github.com/martinbaker/fricas/blob/master/src/algebra/graph.spad.pamphlet
>
several (mostly small) problems:
1) Unicode characters in comments, this causes compilation
failures in some locales (notably C locale).
2) Your nodes are from some set, but on input you only allow
specifying arrows by indices (numbers). IMHO it is much
more elegant to specify arrows giving from and to nodes.
That is have:
addArrow! : (%, String, S, S) -> %
Version with numbers should be only used for efficiency or
in code when numbers are available. It is easy to implement
such funtion by adding:
getVertexIndex(s : %, o : S) : NNI ==
for i in 1.. for v in getVertices(s) repeat
if v.value = o then return i
error "getVertexIndex : vertex not found"
addArrow!(s : %, name : String, o1 : S, o2 : S) : % ==
addArrow!(s, name, getVertexIndex(s, o1), getVertexIndex(s, o2))
I think that getVertexIndex should be exported too.
3) In 'incidenceMatrix' you only take into account starting point
of an arrow. But standard definition also includes endpoint
(you are supposed to be able to reconstruct graph from its
incidence matrix, standard definition allows it, your code
not). Also, for directed graphs entry corresponding to
start point is -1, while for directed graph it is 1.
4) AFAICS FunctionGraph domain and MultifunctionGraph are mostly
redundant:
- Logically they are just graphs that satisfy appropriate
predicate. Given that most operations on graphs do not
preserve this predicate having separate types gives little
gain and IMHO it is better to just provide predicates
'functionGraph? : % -> Boolean' and
'multifunctionGraph? : (S, NNI) -> Boolean'.
- they provide their own representation, but case of
FunctionGraph seem too special to optimize for, and
in case of MultifunctionGraph the representation is
capable of representing arbitrary graphs (in fact,
I feel that it is better representation than the
one used in DirectedGraph). So again I see no
reason for special representation.
- few operations that are special to both domains could
be moved to DirectedGraph
- my impression is that at least MultifunctionGraph allows
you to create graph which does not satisfy its predicate
5) Documentation for your functions shows poorly in HyperDoc.
The normal style is to write something like:
++ addArrow!(s, nm, o1, o2) adds an arrow to the graph s,where:
++ nm is the name of the arrow
++ o1 is the start object
++ o2 is the end object
You wrote:
addArrow!:(s:%,name:String,n1:NNI,n2:NNI) -> %
++ adds an arrow to this graph,where:
++ s is the graph where the arrow is to be added
++ nm is the name of the arrow
++ n1 is the index of the start object
++ n2 is the index of the end object
Unfortunatly, Spad compiler simply ignores names given in the
first line, so HypeDoc shows:
addArrow!(x, y, i, j)
++ adds an arrow to this graph,where:
++ s is the graph where the arrow is to be added
++ nm is the name of the arrow
++ n1 is the index of the start object
++ n2 is the index of the end object
and the user has no idea what are correct arguments to the
function.
6) Parts of documentation are not up to date. For example
in WeightedGraph:
++ At the moment weights are restricted to NNI but I may change that to
++ real (DoubleFloat) numbers.
but AFAICS WeightedGraph already allows weights from
OrderedAbelianMonoid.
I think I could quickly correct most of the above problems,
but I am not sure how you feel about this (in particlar about
getting rid of FunctionGraph and MultifunctionGraph).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Baker
As you suspected its the getting rid of FunctionGraph and
MultifunctionGraph that gives me concern and which I don't want to do.
I agree that they do not currently enforce the fixed number of
outgoing arrows per node at the moment and I would like to add that
(by adding a NNI domain parameter). FunctionGraph could be merged into
MultifunctionGraph with a domain parameter of 1.
There are a lot reasons why I think it is important to have efficient
implementations of these types of structures. One reason is that I
would like to link this to the computational framework, as a
complimentary way to represent functions and to model the dynamics of
cellular automata (state transition diagrams).
see the section entitled 'Graphs of functions' in:
http://en.wikipedia.org/wiki/Pseudoforest
I would also like to have this as a general structure which can link
up to other structures like groups and lattices (for example
factorising groups into cosets).
I agree there is a lot of overlap between these domains and
DirectedGraph and it would be good to reduce this duplication. There
are also a lot of functionality in FunctionGraph and
MultifunctionGraph that are not duplicated and rely on the fixed
number of outgoing arrows per node, I would not want to loose this
stuff so these would all have to be migrated into any new
architecture.
I was thinking that the ideas you had earlier, separation of the
algorithms into a table representation might remove a lot of this
duplication so my plan was to leave this until I saw what you came up
with here.
It depends what your timescales are, if you are still planning to
release in the next day or so then I'm really keen to leave
FunctionGraph and MultifunctionGraph in for now rather than make
rushed changes and review the overall architecture when we have more
time.
I am happy for you to make the other changes (you can probably do them
quicker than me) but if I can help let me know.
Martin
Martin Baker
> 1) Unicode characters in comments, this causes compilation
> failures in some locales (notably C locale).
stop it happening in the future (I have never used vi or Emacs as I
did not want to learn the keycodes)
> 5) Documentation for your functions shows poorly in HyperDoc.
> The normal style is to write something like:
>
> ++ addArrow!(s, nm, o1, o2) adds an arrow to the graph s,where:
> ++ nm is the name of the arrow
> ++ o1 is the start object
> ++ o2 is the end object
>
> You wrote:
>
> addArrow!:(s:%,name:String,n1:NNI,n2:NNI) -> %
> ++ adds an arrow to this graph,where:
> ++ s is the graph where the arrow is to be added
> ++ nm is the name of the arrow
> ++ n1 is the index of the start object
> ++ n2 is the index of the end object
>
> Unfortunatly, Spad compiler simply ignores names given in the
> first line, so HypeDoc shows:
>
> addArrow!(x, y, i, j)
>
> ++ adds an arrow to this graph,where:
> ++ s is the graph where the arrow is to be added
> ++ nm is the name of the arrow
> ++ n1 is the index of the start object
> ++ n2 is the index of the end object
>
> and the user has no idea what are correct arguments to the
> function.
there are so many compiler warnings that I just ignore them, however I
was going to try to investigate this when I found time. Is there any
documentation about the documentation that explains what it is trying
to enforce and why?
Martin
Waldek Hebisch
>
> Waldek,
>
> As you suspected its the getting rid of FunctionGraph and
> MultifunctionGraph that gives me concern and which I don't want to do.
>
> It depends what your timescales are, if you are still planning to
> release in the next day or so then I'm really keen to leave
> FunctionGraph and MultifunctionGraph in for now rather than make
> rushed changes and review the overall architecture when we have more
> time.
>
> I am happy for you to make the other changes (you can probably do them
> quicker than me) but if I can help let me know.
>
OK, I will go on with the release keeping FunctionGraph and
MultifunctionGraph and we will come back to this after release.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
>
> OK, I will go on with the release keeping FunctionGraph and
> MultifunctionGraph and we will come back to this after release.
>
All changes that I wanted to do for the release are now commited.
I am waiting for the fix for Aldor interface. Assuming no
new important problem appears I will then create release
branch and proceed with final testing before release.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> All changes that I wanted to do for the release are now commited.
> I am waiting for the fix for Aldor interface.
Since I have no experience with "norm-out"... just to make sure before
committing. The attached output looks OK to you?
It basically compares r1339 DIR1 with my patched version DIR2.
This change in the number of unexposed functions probably comes from
adding graph.spad to the building process?
Ralf
Waldek Hebisch
>
> This is a multi-part message in MIME format.
> --------------000805090005020305020707
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Yes, everything OK.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> Usually the situation is that I work on the code (in seperate spad
> files) and documentation (in pamphlet file).
Well, everyone does as s/he likes, but why working in two different
files? All you need is a program that extracts the .spad file from the
pamphlet file. The "document" script is such a program. You find it as
build/scripts/document
in your *build* directory.
See src/algebra/Makefile.in for examples of how to use it.
${INPUT}/TESTFR.input: $(srcdir)/fr.spad.pamphlet
$(axiom_build_document) --tangle='TEST FR' --output=$@ $<
> So when I wish to publish
> I do the following:
> 1) cut and paste all the seperate .spad files back into pamphlet file.
More time wasted than when a Makefile is used with the commands to
extract your .spad files.
> 2) download the master pamphlet file to my local computer.
??? You are using git. This sounds as if you *don't* have a git-clone on
your local computer. Have you?
> 3) compare my new pamphlet file with master just downloaded by using
> KDiff3 program and resolve any differences.
??? Just commit the new file and be done. Git does the rest.
> 4) if there have been any changes by Waldek then untangle (using cut
> and paste) this back into seperate .spad files.
You should rather use git rebase for that. Git will tell you if it
cannot resolve conflicts.
> 5) check that they still compile in case there is some interaction
> between my and Waldeks changes.
That's always a good idea.
> 6) upload new pamphlet file to github
I guess, you can only use "git push" for that.
> Upto now this has worked although it is very tedious.
... and unnecessarily complex.
> Recently there was a problem with matrix and scene files and I think
> this is because I started to use a program called 'Kile' to edit
> the pamphlet files (as it has some help with LaTeX commands).
Well, LaTeX seems to be a big problem for you. OK it's not the easiest
thing for someone not familiar with it, but learning a bit more about
LaTeX might also help you in other places to write nice-looking
documents. You actually don't need a lot of commands.
> I guess its always going to be a problem using such a program to
> edit a file that contains a mixture of Tex and code.
I never really used Kile since Emacs works perfectly for me. Maybe you
want to use gedit or nano if you are not happy with emacs or vim.
To help you a bit with git... I took some time to put your code on top
of master and while doing that merge in all the latest things that
happened on master. If I didn't do anything wrong, then it contains all
the code that is not yet in trunk.
I squashed all commits together since I think the history is mostly
irrelevant. What counts is the history of trunk (until fricas switches
to git completely).
Anyway, let me suggest a new workflow for you.
One-time operation:
Get my martin-baker branch into your local fricas clone.
git remote add hemmecke git://github.com/hemmecke/fricas.git
git fetch hemmecke
Maybe you want to rename you master branch to oldmaster and my
martin-baker branch to become your new master.
First commit any pending things locally!!!
Then
git checkout master
git branch oldmaster
git reset --hard hemmecke/martin-baker
Look at
https://github.com/hemmecke/fricas-svn/commit/809c1c675b676061fee84f4d9bdd88c4c346adae
You might want to add your other files in a similar way so that they
become part of the ordinary (local) build process. In that way, you can
much better check whether some of your code breaks something else in
FriCAS and whether the whole build process also works if your code is
included into trunk.
Workflow as follows. (Assumption all your files are in the ordinary
build process). Example: graph.spad.pamphlet
Time consuming version:
* modify graph.spad.pamphlet
* commit your changes
* Go to some empty directory outside the fricas source tree and type
/path/to/your/fricas-clone/configure --prefix=$HOME/software --enable-gmp
make -j n > make.log 2>&1
# where n is the number of cores of your machine
# You can see the progress of the build via
# "tail -f make.log" entered in another console.
make install
$HOME/software/fricas
Since nothing actually builds on your code, the above is certainly too
much for rapid development you might want to do the following.
* modify graph.spad.pamphlet
* commit your changes
* on the unix command line call "compile.sh FILE"
* in fricas load the libraries via ")read lib.input"
The attached file compile.sh might not work since it assumes that it has
to compile the files in the order they appear in the respective
.pamphlet file, but I guess, you can adapt that.
cd /some/scratch/directory
sh compile.sh /path/to/your/fricas-clone/src/algebra/graph.spad.pamphlet
If the compilation does not work out, simply
modify your file again. then say
git commit -a --amend
and compile again until your code is satisfactory.
Whenever trunk changes, you fetch new code from hemmecke/fricas-svn.
git remote add upstream git://github.com/hemmecke/fricas-svn.git
# you probably already have this
Then
git fetch upstream
to get trunk(=upstream/master).
Now rebase your changes on top of upstream/master.
git rebase upstream/master
If you run into a merge conflict, you'd resolve this via
git mergetool
git rebase --continue
That will keep your code close to trunk and modifications done by Waldek
on graph.spad.pamphlet on trunk will more easily enter into your branch.
After rebasing, you will probably have to force your push to github,
because it will be a non-fast-forward change.
git push -f origin master
I hope you find some helpful things in this post
Best regards
Ralf
Waldek Hebisch
>
> This is a multi-part message in MIME format.
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Martin,
>
> > Usually the situation is that I work on the code (in seperate spad
> > files) and documentation (in pamphlet file).
>
> Well, everyone does as s/he likes, but why working in two different
> files? All you need is a program that extracts the .spad file from the
> pamphlet file. The "document" script is such a program. You find it as
>
> build/scripts/document
>
> in your *build* directory.
>
> > 1) cut and paste all the seperate .spad files back into pamphlet file.
>
> More time wasted than when a Makefile is used with the commands to
> extract your .spad files.
Makefile and merging is a one time effort. However the main
thing is actual developement. With separate file you can
compile Spad file and imediately test is (reusing commands
and data from the history). You can try to approximate it
using ')lib' in running FriCAS after 'make'. However,
that means extra commands and context switching compared
to ')compile'. In case of dependencies Makefile is going
to be more complicated: you need to set '$bootStrapMode'
and/or dump databases. Also, to avoid needless recompilation
(simple Makefile will recompile all files contained in a
pamphlet) you need extra logic in Makefile.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
>>
>> More time wasted than when a Makefile is used with the commands to
>> extract your .spad files.
>
> Makefile and merging is a one time effort. However the main
> thing is actual developement. With separate file you can
> compile Spad file and imediately test is (reusing commands
> and data from the history). You can try to approximate it
> using ')lib' in running FriCAS after 'make'. However,
> that means extra commands and context switching compared
> to ')compile'. In case of dependencies Makefile is going
> to be more complicated: you need to set '$bootStrapMode'
> and/or dump databases. Also, to avoid needless recompilation
> (simple Makefile will recompile all files contained in a
> pamphlet) you need extra logic in Makefile.
I could probably also just put everything into a compile.input file and
call the 'document --tangle=..." command via ")system ..." from inside
fricas. Maybe it would be a good idea to enable something like
)compile graph.spad.pamphlet )domain FGRPH
so that domain FGRPH.spad would be extracted via "document" and compiled
in the usual way.
Anyway, as I said, it was a suggestion and basically the main point I
wanted to make is to use git in a more straighforward way in order to
keep Martin's code closer to trunk as it is now.
Anyone can have the workflow he/she wants. I don't force anyone to
follow my suggestions.
Ralf
PS: I don't think that any code as high-level as Martin's Graph code
should have any need to use $bootStrapMode.
Martin Baker
> I hope you find some helpful things in this post
Yes, thanks it looks very useful, last year sometime we also had an
interesting exchange of e-mails about github and, from that, I drew up
this diagram:
http://www.euclideanspace.com/software/development/github/workflow/
I tend to think graphically and it is only when I can get everything I
need to know about a subject onto one diagram that I start to think
that it may be simple enough to use (I must admit I don't follow that
rule for Axiom/FriCAS!).
I'm not sure if this diagram is quite right. I get the impression that
the 'git checkout' command swaps around the directory contents and I
don't know how to show that.
Anyway, I'll look at this new information you have sent, and see if I
can get that onto the diagram.
Martin
Ralf Hemmecke
> I'm not sure if this diagram is quite right. I get the impression that
> the 'git checkout' command swaps around the directory contents and I
> don't know how to show that.
Now you have 3 boxes trunk, master, fricas. I don't quite get their meaning.
The best thing to think about a git repository is in terms of a Directed
Acyclic Graph (DAG) of commits. Consider this graph being labelled with
the sha-1 numbers. Since identical sha-1 numbers mean identical content,
it doesn't matter where in the world that content is stored. Now,
consider the fricas git repo. that consists of all commits that lead to
the master branch of https://github.com/hemmecke/fricas-svn
In fact, I have another DAG here. https://github.com/hemmecke/fricas
And you have a DAG here. https://github.com/martinbaker/fricas
All three are probably different, but they share quite a big part.
Consider the "fricas git repository" simply as "the repository of every
commit that anyone in the world has ever committed to fricas", i.e. you
consider the union of all commits over all users. That gives a HUGE DAG
(let's call it FRICAS). But by the sha-1 numbers, you are sure that all
the three repos above just form a subgraph of FRICAS. All we are doing
with git, is to modify and extend this FRICAS DAG.
Now, whenever you say "git checkout some-sha-1" git will switch the
files in your working directory to contain exactly the state
corresponding to "some-sha-1".
It's usually. not a big deal to work in the same directory. Git never
override a modified file by "git checkout", but rather aborts and tells
you that you have uncommitted changes. It's actually very hard to lose
some data with git.
Your picture is wrong in so far as you should have just one clone
corresponding to your https://github.com/martinbaker/fricas .
Let's call this clone "fricas". "fricas" has two "remotes" (which you
see by "git remote -v"). Namely,
origin https://github.com/martinbaker/fricas
upstream https://github.com/hemmecke/fricas-svn
You can fetch data from any of these remotes. (Remember the big FRICAS
DAG. Basically, with adding more and more remotes, you have access to a
bigger part of FRICAS. But one usually only concentrates on a few
remotes (like upstream) and ignores what other people do with fricas.)
trunk and master are just local names for branches. Nothing fancy with
these names. The important things are actually the sha-1's.
It looks as the fricas box in your picture is the so-called working
directory whereas the trunk and master boxes correspond to branches.
BTW, instead of "git merge" I have suggested "git rebase" in my previous
mail. Learn about this difference. Since we still have to deal with an
SVN official repository, that does matter.
http://book.git-scm.com/4_rebasing.html
http://gitready.com/intermediate/2009/01/31/intro-to-rebase.html
Ralf