open-axiom-devel Mailing List for OpenAxiom: Scientific Computation System
A system for computer algebra and symbolic mathematics
Brought to you by:
dos-reis
You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(73) |
Sep
(57) |
Oct
(138) |
Nov
(91) |
Dec
(99) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(91) |
Feb
(53) |
Mar
(37) |
Apr
(125) |
May
(176) |
Jun
(23) |
Jul
(135) |
Aug
(119) |
Sep
(26) |
Oct
(38) |
Nov
(46) |
Dec
(11) |
2009 |
Jan
(4) |
Feb
(2) |
Mar
(5) |
Apr
(15) |
May
(4) |
Jun
(18) |
Jul
(1) |
Aug
(4) |
Sep
(17) |
Oct
(9) |
Nov
(14) |
Dec
(11) |
2010 |
Jan
(9) |
Feb
(6) |
Mar
(1) |
Apr
(1) |
May
(4) |
Jun
(3) |
Jul
|
Aug
(10) |
Sep
(7) |
Oct
(7) |
Nov
(36) |
Dec
(23) |
2011 |
Jan
(2) |
Feb
(1) |
Mar
(1) |
Apr
(11) |
May
(5) |
Jun
(17) |
Jul
(2) |
Aug
(26) |
Sep
(14) |
Oct
(51) |
Nov
(39) |
Dec
(7) |
2012 |
Jan
(24) |
Feb
(7) |
Mar
(9) |
Apr
(2) |
May
(9) |
Jun
(7) |
Jul
(3) |
Aug
(1) |
Sep
(8) |
Oct
(12) |
Nov
(1) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
(35) |
May
(28) |
Jun
(14) |
Jul
(10) |
Aug
(3) |
Sep
(6) |
Oct
|
Nov
(1) |
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(3) |
Jun
(2) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(3) |
Nov
(5) |
Dec
(8) |
2015 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2016 |
Jan
(5) |
Feb
(10) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
2017 |
Jan
(2) |
Feb
(2) |
Mar
(5) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Bill P. <bil...@ne...> - 2017-04-05 17:27:39
|
Is OpenAxiom committed to maintaining the pamphlet form of the algebra files that it inherited from the original Axiom project? FriCAS has abandoned this in favor of just spad files. After working with FriCAS for a while I find the return to pamphlet files awkward. In particular it interferes with using language specific customizations of editors such as vi and atom. Would you be interested/willing to return to using just spad files for the algebra? |
From: Mark C. <mar...@ki...> - 2017-03-22 23:03:35
|
Bill, Thank you for following up on this. This is a nice illustration of how to extend pan-Axiom to deal with a specific case. One of the advantages of algorithmic differentiation (AD) is that we can rapidly differentiate across a range of operators and expressions. One could re-write the previous example using an iterative function: )set message time on g(x) == expr := 1+x for i in 1..10000 repeat expr := expr*(1+x) expr eval(D(g(x),x),x=0.1) -- very slow g(jet(0.1)) -- fast )set message time off The symbolic solution takes about 30 seconds on my laptop, while the AD solution was 500-1000 times faster. I have extended the "Jet" package: to include some more operators; allow for coersion from T to Jet(T); and defined the export category as Join(PartialOrder,IntegralDomain), which now supports eval(). One can now write: reduce(+, vector [1,2,3*jet(3)]) -- and eval(x^exp(x)^exp(x), x=jet(0.1)) -- Mark On 03/20/2017 06:46 PM, Bill Page wrote: > Oops, I forgot to add one line of output > > (3) -> distribute(%)::Float > > (3) 0.7681727501_0912254214 E 418 > Type: Float > Time: 0 sec > > 'distribute' is the operator that "undoes" 'paren'. > > On 20 March 2017 at 13:32, Bill Page <bil...@ne...> wrote: >> The problem is just the expansion of (1+x)^10000. >> >> (1) -> )set message time on >> >> (1) -> g(x) == (1+x)^10000 >> Type: Void >> Time: 0 sec >> (2) -> eval(D(g(x),x), x=0.1) >> Compiling function g with type Variable x -> Polynomial Integer >> >> Type: Polynomial Float >> Time: 3.09 (IN) + 6.74 (EV) + 0.06 (OT) = 9.89 sec >> >> In FriCAS and OpenAxiom (probably Axiom too) the correct way to avoid >> this is to treat (1+x) as a kernel via the identity operator 'paren'. >> >> (3) -> g(x) == paren(1+x)^10000 >> Compiled code for g has been cleared. >> 1 old definition(s) deleted for function or rule g >> Type: Void >> Time: 0 sec >> (4) -> eval(D(g(x),x), x=0.1) >> Compiling function g with type Variable x -> Expression Integer >> 9999 , >> (4) 10000.0 (1.1) %paren (1.1) >> >> Type: Expression Float >> Time: 0.09 (IN) + 0.05 (OT) = 0.14 sec >> >> The only trouble here is that neither FriCAS nor OpenAxiom know how to >> differentiate this operator. This can be fixed with the following >> patch: >> >> https://github.com/billpage/fricas/commit/04c1f9b2d5eb4ece95c6f5dded46a72181cecb06 >> https://github.com/billpage/fricas/commit/04c1f9b2d5eb4ece95c6f5dded46a72181cecb06.patch >> >> (1) -> g(x) == paren(1+x)^10000 >> Type: Void >> Time: 0 sec >> (2) -> eval(D(g(x),x), x=0.1) >> Compiling function g with type Variable(x) -> Expression(Integer) >> >> 9999 >> (2) 10000.0 (1.1) >> Type: Expression(Float) >> Time: 0.04 (IN) + 0.00 (EV) + 0.12 (OT) = 0.16 sec >> |
From: Bill P. <bil...@ne...> - 2017-03-20 17:57:17
|
The problem is just the expansion of (1+x)^10000. (1) -> )set message time on (1) -> g(x) == (1+x)^10000 Type: Void Time: 0 sec (2) -> eval(D(g(x),x), x=0.1) Compiling function g with type Variable x -> Polynomial Integer Type: Polynomial Float Time: 3.09 (IN) + 6.74 (EV) + 0.06 (OT) = 9.89 sec In FriCAS and OpenAxiom (probably Axiom too) the correct way to avoid this is to treat (1+x) as a kernel via the identity operator 'paren'. (3) -> g(x) == paren(1+x)^10000 Compiled code for g has been cleared. 1 old definition(s) deleted for function or rule g Type: Void Time: 0 sec (4) -> eval(D(g(x),x), x=0.1) Compiling function g with type Variable x -> Expression Integer 9999 , (4) 10000.0 (1.1) %paren (1.1) Type: Expression Float Time: 0.09 (IN) + 0.05 (OT) = 0.14 sec The only trouble here is that neither FriCAS nor OpenAxiom know how to differentiate this operator. This can be fixed with the following patch: https://github.com/billpage/fricas/commit/04c1f9b2d5eb4ece95c6f5dded46a72181cecb06 https://github.com/billpage/fricas/commit/04c1f9b2d5eb4ece95c6f5dded46a72181cecb06.patch (1) -> g(x) == paren(1+x)^10000 Type: Void Time: 0 sec (2) -> eval(D(g(x),x), x=0.1) Compiling function g with type Variable(x) -> Expression(Integer) 9999 (2) 10000.0 (1.1) Type: Expression(Float) Time: 0.04 (IN) + 0.00 (EV) + 0.12 (OT) = 0.16 sec On 9 March 2017 at 16:58, Mark Clements <mar...@ki...> wrote: > [Apologies for cross-posting] > > For the algorithmic differentiation: I have started an implementation > (attached) of the jet machinery using a domain rather than the > domain+package used in Smith et al. > > This provides considerably faster differentiation than symbolic > differentiation. For example: > > g(x) == (1+x)^10000 > eval(D(g(x),x), x=0.1) -- slow > g(jet(0.1)) -- fast! > > I was not certain how to get x=jet(1.0) or eval(x^x, x=jet(2.0)) to work: > any suggestions? > > Sincerely, Mark, > > > On 02/19/2017 12:21 PM, Gabriel Dos Reis wrote: > > It was available in a branch of OpenAxiom. Jacob wanted to rewrite for > merging in the main trunk. He graduated and got a job, so did not get to > rewrite it. I added the AST part of the work to the trunk, but the jet > machinery remained in Jacob's branch. > > Jacob: do you still have that? > > -- Gaby > > > On Feb 19, 2017 3:15 AM, "Mark Clements" <mar...@ki...> wrote: > > Is the Axiom code for Smith's work on algorithmic differentiation > available? > > http://www.axiomatics.org/~gdr/ad/issac07.pdf > http://oaktrust.library.tamu.edu/bitstream/handle/1969.1/ETD-TAMU-2010-05-7823/SMITH-DISSERTATION.pdf > > Sincerely, Mark Clements. > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > open-axiom-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/open-axiom-devel > > > > -- > You received this message because you are subscribed to the Google Groups > "FriCAS - computer algebra system" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to fri...@go.... > To post to this group, send email to fri...@go.... > Visit this group at https://groups.google.com/group/fricas-devel. > For more options, visit https://groups.google.com/d/optout. |
From: Bill P. <bil...@ne...> - 2017-03-20 17:46:12
|
Oops, I forgot to add one line of output (3) -> distribute(%)::Float (3) 0.7681727501_0912254214 E 418 Type: Float Time: 0 sec 'distribute' is the operator that "undoes" 'paren'. On 20 March 2017 at 13:32, Bill Page <bil...@ne...> wrote: > The problem is just the expansion of (1+x)^10000. > > (1) -> )set message time on > > (1) -> g(x) == (1+x)^10000 > Type: Void > Time: 0 sec > (2) -> eval(D(g(x),x), x=0.1) > Compiling function g with type Variable x -> Polynomial Integer > > Type: Polynomial Float > Time: 3.09 (IN) + 6.74 (EV) + 0.06 (OT) = 9.89 sec > > In FriCAS and OpenAxiom (probably Axiom too) the correct way to avoid > this is to treat (1+x) as a kernel via the identity operator 'paren'. > > (3) -> g(x) == paren(1+x)^10000 > Compiled code for g has been cleared. > 1 old definition(s) deleted for function or rule g > Type: Void > Time: 0 sec > (4) -> eval(D(g(x),x), x=0.1) > Compiling function g with type Variable x -> Expression Integer > 9999 , > (4) 10000.0 (1.1) %paren (1.1) > > Type: Expression Float > Time: 0.09 (IN) + 0.05 (OT) = 0.14 sec > > The only trouble here is that neither FriCAS nor OpenAxiom know how to > differentiate this operator. This can be fixed with the following > patch: > > https://github.com/billpage/fricas/commit/04c1f9b2d5eb4ece95c6f5dded46a72181cecb06 > https://github.com/billpage/fricas/commit/04c1f9b2d5eb4ece95c6f5dded46a72181cecb06.patch > > (1) -> g(x) == paren(1+x)^10000 > Type: Void > Time: 0 sec > (2) -> eval(D(g(x),x), x=0.1) > Compiling function g with type Variable(x) -> Expression(Integer) > > 9999 > (2) 10000.0 (1.1) > Type: Expression(Float) > Time: 0.04 (IN) + 0.00 (EV) + 0.12 (OT) = 0.16 sec > |
From: Gabriel D. R. <gd...@in...> - 2017-03-12 07:00:50
|
Reimplementing AXIOM systems with a Hindley-Milner style polymorphism will take the computer algebra community at least three or four decades back -- with no improvement. -- Gaby On Fri, Mar 3, 2017 at 4:21 PM, Tim Daly <axi...@gm...> wrote: > Jeremy, > > I read Wadler's paper. I find it amusing because these ideas were > implemented in Axiom long before the paper was published. > (http://202.3.77.10/users/karkare/courses/2010/cs653/ > Papers/ad-hoc-polymorphism.pdf) > > One advantage, though, is their formalization. In the computer > algebra world there was work by Santas "A Type System for > Computer Algebra (http://daly.axiom-developer.org/Sant95.pdf) > who visited the Axiom group at IBM Research. > > Axiom introduces the idea of "conditional categories" which does > not seem to be anywhere else. (see Santas paper) You can say > > C0: Category == with (if % has Ring then Ring) > > so you can assert Ring in the current Domain (called %) > if the Category chain includes Ring. Knowing that, the > Domain (Instance in Lean) can conditionally add functions > > D0 : C0 == > > if % has Ring then > foo: % -> % > > Axiom was far ahead of its time and once it has a proof mechanism > it will be far ahead of all other computer algebra systems. > > I'd really like to replace the current type-resolution machinery in Axiom > with a more formal approach. The compiler requires explicit types > everywhere. The interpreter does type inference. It would be interesting > to re-implement it using a Hindley/Milner style machine. I suspect that > would raise some interesting research questions as Axiom implements > a very general coerce/convert mechanism. Even so, there are special > cases hard-coded into the interpreter. > > A theory-based machine would be much easier to prove correct. > > Tim > > > > > _______________________________________________ > Axiom-developer mailing list > Axi...@no... > https://lists.nongnu.org/mailman/listinfo/axiom-developer > > |
From: Mark C. <mar...@ki...> - 2017-03-09 21:58:10
|
[Apologies for cross-posting] For the algorithmic differentiation: I have started an implementation (attached) of the jet machinery using a domain rather than the domain+package used in Smith et al. This provides considerably faster differentiation than symbolic differentiation. For example: g(x) == (1+x)^10000 eval(D(g(x),x), x=0.1) -- slow g(jet(0.1)) -- fast! I was not certain how to get x=jet(1.0) or eval(x^x, x=jet(2.0)) to work: any suggestions? Sincerely, Mark, On 02/19/2017 12:21 PM, Gabriel Dos Reis wrote: It was available in a branch of OpenAxiom. Jacob wanted to rewrite for merging in the main trunk. He graduated and got a job, so did not get to rewrite it. I added the AST part of the work to the trunk, but the jet machinery remained in Jacob's branch. Jacob: do you still have that? -- Gaby On Feb 19, 2017 3:15 AM, "Mark Clements" <mar...@ki...<mailto:mar...@ki...>> wrote: Is the Axiom code for Smith's work on algorithmic differentiation available? http://www.axiomatics.org/~gdr/ad/issac07.pdf<http://www.axiomatics.org/%7Egdr/ad/issac07.pdf> http://oaktrust.library.tamu.edu/bitstream/handle/1969.1/ETD-TAMU-2010-05-7823/SMITH-DISSERTATION.pdf Sincerely, Mark Clements. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! <http://sdm.link/slashdot> http://sdm.link/slashdot _______________________________________________ open-axiom-devel mailing list ope...@li...<mailto:ope...@li...> https://lists.sourceforge.net/lists/listinfo/open-axiom-devel |
From: Gabriel D. R. <do...@gm...> - 2017-02-19 11:21:20
|
It was available in a branch of OpenAxiom. Jacob wanted to rewrite for merging in the main trunk. He graduated and got a job, so did not get to rewrite it. I added the AST part of the work to the trunk, but the jet machinery remained in Jacob's branch. Jacob: do you still have that? -- Gaby On Feb 19, 2017 3:15 AM, "Mark Clements" <mar...@ki...> wrote: Is the Axiom code for Smith's work on algorithmic differentiation available? http://www.axiomatics.org/~gdr/ad/issac07.pdf http://oaktrust.library.tamu.edu/bitstream/handle/1969.1/ ETD-TAMU-2010-05-7823/SMITH-DISSERTATION.pdf Sincerely, Mark Clements. ------------------------------------------------------------ ------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ open-axiom-devel mailing list ope...@li... https://lists.sourceforge.net/lists/listinfo/open-axiom-devel |
From: Mark C. <mar...@ki...> - 2017-02-19 11:15:46
|
Is the Axiom code for Smith's work on algorithmic differentiation available? http://www.axiomatics.org/~gdr/ad/issac07.pdf http://oaktrust.library.tamu.edu/bitstream/handle/1969.1/ETD-TAMU-2010-05-7823/SMITH-DISSERTATION.pdf Sincerely, Mark Clements. |
From: Gabriel D. R. <gd...@in...> - 2017-01-25 08:18:10
|
I was largely poking, tongue in cheek, at the earlier syllogism: >> The point is that Lisp has a formal logic basis and, as Spad is really >> just a domain specific language implemented in Lisp then Spad shares >> the formal logic basis. -- Gaby On Thu, Jan 12, 2017 at 10:35 PM, Tim Daly <axi...@gm...> wrote: > > There were implementations of C in Lisp. So C shares that formal logic > basis, or that it was discovered? > > According to Wadler, C is an "invented" language, not a "discovered" > language. > > Wadler (https://www.youtube.com/watch?v=aeRVdYN6fE8) at around 40 minutes > shows the logician's view versus the computer science view of various > theories. > He makes a distinction betwen invented and discovered langauges. > > (begin quote of Wadler) > > Every interesting logic has a corresponding language feature: > > Natural Deduction (Gentzen) <==> Typed Lambda Calculus (Church) > Type Schemes (Hindley) <==> ML Type System (Milner) > System F (Girard) <==> Polymorphic Lambda Calculus (Reynolds) > Modal Logic (Lewis) <==> Monads (state, exceptions) (Kleisli, Moggi) > Classical-Intuitionistic Embedding (Godel) <==> Continuation Passing > (Reynolds) > Linear Logic (Girard) <==> Session Types (Honda) > > Languages which were "discovered" (based on theory): > > Lisp (McCarthy) > Iswim (Landin) > Scheme (Steele and Sussman) > ML (Milner, Gordon, Wadsworth) > Haskell (Hudak, Hughes, Peyton Jones, Wadler) > O'Caml (Leroy) > Erlang (Armstrong, Virding, Williams) > Scala (Odersky) > F# (Syme) > Clojure (Hickey) > Elm (Czaplicki) > > At about minute 43 we hear: > > "Not all of these languages are based on lambda calculus ... > but there is a core that is "discovered". Now most of you work > in languages like Java, C++, or Python and those languages I will > claim are not discovered; they are "invented". Looking at them > you can tell they are invented. So this is my invitation to you > to work in languages that are "discovered". > > Somebody asked before about "dependent types". It turns out that > when you extend into dependent types you now get languages that > have "for all" and "there exists" that corresponds to a feature > called "dependent types". So this means that you can encode very > sophisticated proofs, pretty much everything you can name as a > program. And so the standard way to get a computer to check a > proof for you and to help you with that proof is to represent that > as a program in typed lambda calculus. > > All of these systems are based on a greater or lesser extent on > that idea: > > Automath (de Bruijn) > Type Theory (Martin Lof) > Mizar (Trybulec) > ML/LCF (Milner, Gordon, Wadsworth) > NuPrl (COnstable) > HOL (Gordon, Melham) > Coq (Huet, Coquand) > Isabelle (Paulson) > Epigram (McBride, McKinna) > Agda (Norell) > > (end quote) > > Axiom is using Coq for its proof platform because Axiom needs > dependent types (e.g. specifying matrix sizes by parameters). > > In addition, Coq is capable of generating a program from a > proof and the plan is to reshape the Spad solution to more > closely mirror the proof-generated code. Also, of course, we need > to remove any errors in the Spad code found during proofs. > > It seems there must be an isomorphism between Coq and Spad. > > At the moment it seems that Coq's 'nat' matches Axiom's > NonNegativeInteger. Coq also has a 'Group' type which needs > to be matched with the Axiom type. The idea is to find many > isomorphisms of primitive types which will generate lemmas > that can be used to prove more complex code. > > Given that Axiom has an abstract algebra scaffold it seems likely > that a reasonable subset can be proven (modulo the fact that there > are arguable differences from the abstract algebra type hierarchy). > > Currently Coq is run during the Axiom build to check any proofs > of Spad code that are included. ACL2 is also run during the build > to check any proofs of Lisp code that are included. > > I'm taking a course at Carnegie-Mellon this semester using Lean > (a Coq offshoot) in order to try to make some working examples > of proving Spad code correct. > > > On Thu, Jan 12, 2017 at 10:14 PM, Gabriel Dos Reis < > gd...@in...> wrote: > >> There were implementations of C in Lisp. So C shares that formal logic >> basis, or that it was discovered? >> >> On Wed, Jan 11, 2017 at 8:17 PM, Tim Daly <axi...@gm...> wrote: >> >>> I'm making progress on proving Axiom correct both at the Spad level and >>> the Lisp level. One interesting talk by Phillip Wadler on "Propositions >>> as >>> Types", a very entertaining talk, is here: >>> https://www.youtube.com/watch?v=IOiZatlZtGU >>> >>> He makes the interesting point late in the talk that some languages are >>> "discovered" based on fundamental logic principles (e.g.Lisp) and others >>> are "invented" with no formal basis (e.g. C). As he says, "you can tell >>> whether your language is discovered or invented". >>> >>> The point is that Lisp has a formal logic basis and, as Spad is really >>> just a domain specific language implemented in Lisp then Spad shares >>> the formal logic basis. >>> >>> >>> >>> _______________________________________________ >>> Axiom-developer mailing list >>> Axi...@no... >>> https://lists.nongnu.org/mailman/listinfo/axiom-developer >>> >>> >> > |
From: Gabriel D. R. <gd...@in...> - 2017-01-13 03:14:35
|
There were implementations of C in Lisp. So C shares that formal logic basis, or that it was discovered? On Wed, Jan 11, 2017 at 8:17 PM, Tim Daly <axi...@gm...> wrote: > I'm making progress on proving Axiom correct both at the Spad level and > the Lisp level. One interesting talk by Phillip Wadler on "Propositions as > Types", a very entertaining talk, is here: > https://www.youtube.com/watch?v=IOiZatlZtGU > > He makes the interesting point late in the talk that some languages are > "discovered" based on fundamental logic principles (e.g.Lisp) and others > are "invented" with no formal basis (e.g. C). As he says, "you can tell > whether your language is discovered or invented". > > The point is that Lisp has a formal logic basis and, as Spad is really > just a domain specific language implemented in Lisp then Spad shares > the formal logic basis. > > > > _______________________________________________ > Axiom-developer mailing list > Axi...@no... > https://lists.nongnu.org/mailman/listinfo/axiom-developer > > |
From: Gabriel D. R. <gd...@in...> - 2016-12-27 07:05:55
|
On Tue, Sep 13, 2016 at 7:33 PM, oldk1331 <old...@gm...> wrote: > > My policy concerning optimizations was mostly reactive. > > I look at profile data and try to eliminate expensive > > part. > > This is List, the most basic data structure Agreed. List is fundamental in the AXIOMs, just like integer types. The OpenAxiom compiler will inline List operations under the default optimization level -- thanks to domain inlining I implemented a few years back. -- Gaby |
From: Gabriel D. R. <gd...@in...> - 2016-12-27 07:02:58
|
On Tue, Sep 13, 2016 at 6:12 PM, Waldek Hebisch <he...@ma...> wrote: > oldk1331 wrote: > > > > I see this change in openaxiom, > > https://github.com/GabrielDosReis/open-axiom/commit/ > 67f8ca75d03aad7f041d8650ddca4d4cd0b71371 > > > > It seems reasonable, but instead of remove map/map!, > > we should move it into PrimitiveArray. > > (BTW, map/map! in PrimitiveArray is from IndexedAggregate, > > much slower than IARRAY.) > > > > Should I make this change? > > Inheriting from PrimitiveArray is dangerous: due to different > indexing all operations from PrimitiveArray are potentially > wrong for IARRAY. Operations which are safe to inherit are > exceptional. So the Open Axiom change looks undesirable. > I believe that inheritance is correct and safe in OpenAxiom. I don't know whether it is appropriate in other AXIOMs. OpenAxiom implements domain inlining, which takes advantage of domain inheritance. -- Gaby |
From: Bill P. <bil...@ne...> - 2016-12-26 18:00:43
|
There are other things to write about but first just a note about LLVM. I have been following a project called CLASP https://github.com/drmeister/clasp . It is still rather pre-beta with a fairly slow but steady rate of development but in principle might eventually be a path from *AXIOM to LLVM. I understand however that you are targeting LLVM more directly so I am not sure if CLASP is at all relevant to you. In terms of algebra I am still keen to implement some kind of generalization of the Expression domain to encompass first of all a major part of non-commutative involutive algebra https://en.wikipedia.org/wiki/*-algebra . My motivation actually originates with a desire to implement Wirtinger Calculus./CR-calculus and some other features relating to the handling of general complex-valued functions. If this is done in what I consider the correct and "deep" manner it would have major implications for the structure of the Axiom library. I have some work in FriCAS here: https://github.com/billpage/fricas/tree/CR-calculus and some more here: http://axiom-wiki.newsynthesis.org/SandBoxWirtinger but Waldek raised a number of very reasonable "objections in principle" to what I was doing and which I could not immediately answer so I started to loose focus on this work. More recently and new contributor to FriCAS re-kindled an interest in Monads in Axiom and in particular the work you did several years ago on Maybe in OpenAxiom. It seems there are significant limitations in the Axiom/FriCAS implementation of SPAD that have (largely) been over come in OpenAxiom. This is one thing in particular that recalled my interesting in doing more in OpenAxiom. I am particularly interested in the 'forall' quantifier extensions that allow many artificial uses of the Package construct to be replaced with much clearer and more compact code. So I am very interested to see what other features of this type.in OpenAxiom you might be planning. The code for my work on the OpenAxiom gui is here: https://github.com/billpage/open-axiom/tree/gui-latex/wip with my last commit on April 7. I think this still builds and works but in the end I was not completely satisfied with the result. After learning a lot more than I really wanted to about the QTTextDocument and QTTextEdit classes http://doc.qt.io/qt-5/richtext.html I started to think that maybe an overall better approach would be to implement the gui worksheet as a single QT document and then integrate OpenAxiom as a custom text object http://doc.qt.io/qt-5/qtextobjectinterface.html . I was very impressed that it was possible to embed such a richly featured text editor into a QT application. The advantage would be immediate access to some rather sophisticated high-level tools for saving and loading documents as well as producing PDF and HTML outputs. Best wishes for the New Year. Bill Page. On 26 December 2016 at 10:54, Gabriel Dos Reis <gd...@in...> wrote: > Hi Bill, > > Happy holidays to you and everybody! > > I have not done as much as I wish on OpenAxiom this year. However, it is > not dead :-) > I am very much open to experiments in OpenAxiom and branches. > > There are quite a few things I would like to do in the coming months: > * Make OpenAxiom less reliant on Lisp, and more native, possibly with an > LLVM backend. LLVM is available on more platforms (I care about) than Lisp > is. The major downside with LLVM, of course, is its policy of frequent API > breaking changes. > > * More algebra work -- this may require more core language work and more > build system work. As you know, OpenAxiom can bootstrap without cached Lisp > intermediate files. Also, I believe OpenAxiom no longer needs an existing > domain database when bootstrapping. That means making changes to the > algebra is now easier. There may be a few kinks to work out. > > * Make OpenAxiom buildable again on Windows platforms. A some point, we > lost that ability, I don't know what happened. That is ironic given my > daytime occupation. :-) I want to accomplish an integration with VS Code to > allow better experience. I would love to see what you did with your > QT-based project here. > > I have more projects in mind, but for the coming year I think this will do, > given my track record :-) > > -- Gaby > > > On Mon, Dec 26, 2016 at 7:07 AM, Bill Page <bil...@ne...> > wrote: >> >> Gaby, >> >> I noticed a recent commit to OpenAxiom on GitHub and it reminded me of >> my New Year's resolution to do more work with Axiom. I did some work >> early-on this year with OpenAxiom QT gui interface (adding LaTeX >> output and extending various features like document save/load, etc.) >> but I did not quite get to the point of making a pull request. Coding >> in QT was a "learning experience" ... There are also a number of >> projects and experiments on the algebra side for most of which I have >> to used FriCAS or Sage. I began to realize that many of the features I >> was missing in FriCAS already existed in OpenAxiom and it occurred to >> me that perhaps I should change my focus. >> >> I was wondering if you have specific plans for OpenAxiom in the coming >> year and whether you would be interested in work that I might commit? >> >> Thanks and Happy New Year. >> >> Bill Page. >> > |
From: Gabriel D. R. <gd...@in...> - 2016-12-26 15:54:07
|
Hi Bill, Happy holidays to you and everybody! I have not done as much as I wish on OpenAxiom this year. However, it is not dead :-) I am very much open to experiments in OpenAxiom and branches. There are quite a few things I would like to do in the coming months: * Make OpenAxiom less reliant on Lisp, and more native, possibly with an LLVM backend. LLVM is available on more platforms (I care about) than Lisp is. The major downside with LLVM, of course, is its policy of frequent API breaking changes. * More algebra work -- this may require more core language work and more build system work. As you know, OpenAxiom can bootstrap without cached Lisp intermediate files. Also, I believe OpenAxiom no longer needs an existing domain database when bootstrapping. That means making changes to the algebra is now easier. There may be a few kinks to work out. * Make OpenAxiom buildable again on Windows platforms. A some point, we lost that ability, I don't know what happened. That is ironic given my daytime occupation. :-) I want to accomplish an integration with VS Code to allow better experience. I would love to see what you did with your QT-based project here. I have more projects in mind, but for the coming year I think this will do, given my track record :-) -- Gaby On Mon, Dec 26, 2016 at 7:07 AM, Bill Page <bil...@ne...> wrote: > Gaby, > > I noticed a recent commit to OpenAxiom on GitHub and it reminded me of > my New Year's resolution to do more work with Axiom. I did some work > early-on this year with OpenAxiom QT gui interface (adding LaTeX > output and extending various features like document save/load, etc.) > but I did not quite get to the point of making a pull request. Coding > in QT was a "learning experience" ... There are also a number of > projects and experiments on the algebra side for most of which I have > to used FriCAS or Sage. I began to realize that many of the features I > was missing in FriCAS already existed in OpenAxiom and it occurred to > me that perhaps I should change my focus. > > I was wondering if you have specific plans for OpenAxiom in the coming > year and whether you would be interested in work that I might commit? > > Thanks and Happy New Year. > > Bill Page. > > |
From: Bill P. <bil...@ne...> - 2016-12-26 15:29:13
|
Gaby, I noticed a recent commit to OpenAxiom on GitHub and it reminded me of my New Year's resolution to do more work with Axiom. I did some work early-on this year with OpenAxiom QT gui interface (adding LaTeX output and extending various features like document save/load, etc.) but I did not quite get to the point of making a pull request. Coding in QT was a "learning experience" ... There are also a number of projects and experiments on the algebra side for most of which I have to used FriCAS or Sage. I began to realize that many of the features I was missing in FriCAS already existed in OpenAxiom and it occurred to me that perhaps I should change my focus. I was wondering if you have specific plans for OpenAxiom in the coming year and whether you would be interested in work that I might commit? Thanks and Happy New Year. Bill Page. |
From: Gabriel D. R. <gd...@in...> - 2016-02-19 11:44:22
|
On Thu, Feb 18, 2016 at 8:39 PM, Bill Page <bil...@ne...> wrote: > Gaby, > > This problem had me scratching my head for a long time. Tonight I > happened to find this: > Thanks, Bill, for the detective work. > > wspage@suse:~> ls -l > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/* > > -rwxr-xr-x 1 wspage users 127544 Feb 18 21:57 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/asq > -rwxr-xr-x 1 wspage users 1152088 Feb 18 22:50 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys > -rwxr-xr-x 1 wspage users 50921520 Feb 18 21:41 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/bootsys > -rwxr-xr-x 1 wspage users 194448 Feb 18 21:57 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/clef > -rwxr-xr-x 1 wspage users 49184816 Feb 18 21:41 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/lisp > lrwxrwxrwx 1 root root 8 Feb 9 08:08 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/open-axiom > -> AXIOMsys > -rwxr-xr-x 1 wspage users 255296 Feb 18 21:57 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/sman > -rwxr-xr-x 1 wspage users 134560 Feb 18 21:58 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/viewAlone > > wspage@suse:~/open-axiom> > > Notice the link with a different date and different owner. I am not > sure exactly when this link was created - presumably some time before > I decided to experiment with building OpenAxiom with the QT4 gui. > After I completely blew away '/usr/local/lib64/open-axiom' and re-ran > the 'make install' it now all works as you describe. My guess is that > first building OpenAxiom without QT installed, then installing QT and > re-building OpenAxiom without first uninstalling it was a bad idea. > Maybe we can alleviate this problem by doing an "rm -rf <libexec-destination>", before the effective installation? > > Anyway, I am happy again. > Good to hear! :-) -- Gaby > > > On 18 February 2016 at 02:46, Gabriel Dos Reis > <gd...@in...> wrote: > > > > On Mon, Feb 15, 2016 at 6:26 AM, Bill Page <bil...@ne...> > > wrote: > >> ... > >> Yes a QT interface would be nice but (re-)implementing HyperDoc and > >> Graphics in QT seems to me like a lot of effort. The current fashion > >> trend however seems to be browser-based interfaces like Jupyter. > > > > > > Yes, the QT front-end should not be seen as excluding a Jupiter > front-end, > > and I would welcome contributions implementing the Jupiter front-end. > > > > Do you think it is worthwhile first porting Kurt's Jupyter FriCAS > kernel to OpenAxiom? I think it is/was his intention that it should be > Axiom-agnostic and run on any flavor. But as I said it is based > rather centrally on Lisp and QuickLisp. As far as I know it has only > been fully tested on FriCAS built with SBCL. > > >> > >> Probably QT5 is a reasonable target. > > > > > > Great! > > > > Have you tried a QT5 build yet? Are there any known challenges in the > difference between QT4 and QT5? > > >> > >> > >> > My personal development environment these days is OS X El Capitan, I > can > >> > have access to OpenSUSE Tumbleweed but only sporadically. I would > have > >> > to rely on you for OpenSUSE Leap -- I am not familiar with its > >> > characteristics. > >> > > >> > >> I can try. > >> > > I can now report success with OpenSUSE Leap and QT4. > > >> > >> At this point I have *both* QT4.8 and QT5 installed. Maybe that is a > >> problem? > > > > That might be the issue. > > > > No, that turns out not to be a problem. > > > ... > > Yes, unfortunately, I cannot reproduce this on the opens use tumbleweed I > > have access to. > > > > Thank you very much for checking and letting me know. > > I think I will try a build with QT5 and see how far I get. > > Bill. > |
From: Bill P. <bil...@ne...> - 2016-02-19 05:04:49
|
Gaby, This problem had me scratching my head for a long time. Tonight I happened to find this: wspage@suse:~> ls -l /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/* -rwxr-xr-x 1 wspage users 127544 Feb 18 21:57 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/asq -rwxr-xr-x 1 wspage users 1152088 Feb 18 22:50 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -rwxr-xr-x 1 wspage users 50921520 Feb 18 21:41 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/bootsys -rwxr-xr-x 1 wspage users 194448 Feb 18 21:57 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/clef -rwxr-xr-x 1 wspage users 49184816 Feb 18 21:41 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/lisp lrwxrwxrwx 1 root root 8 Feb 9 08:08 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/open-axiom -> AXIOMsys -rwxr-xr-x 1 wspage users 255296 Feb 18 21:57 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/sman -rwxr-xr-x 1 wspage users 134560 Feb 18 21:58 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/viewAlone wspage@suse:~/open-axiom> Notice the link with a different date and different owner. I am not sure exactly when this link was created - presumably some time before I decided to experiment with building OpenAxiom with the QT4 gui. After I completely blew away '/usr/local/lib64/open-axiom' and re-ran the 'make install' it now all works as you describe. My guess is that first building OpenAxiom without QT installed, then installing QT and re-building OpenAxiom without first uninstalling it was a bad idea. Anyway, I am happy again. On 18 February 2016 at 02:46, Gabriel Dos Reis <gd...@in...> wrote: > > On Mon, Feb 15, 2016 at 6:26 AM, Bill Page <bil...@ne...> > wrote: >> ... >> Yes a QT interface would be nice but (re-)implementing HyperDoc and >> Graphics in QT seems to me like a lot of effort. The current fashion >> trend however seems to be browser-based interfaces like Jupyter. > > > Yes, the QT front-end should not be seen as excluding a Jupiter front-end, > and I would welcome contributions implementing the Jupiter front-end. > Do you think it is worthwhile first porting Kurt's Jupyter FriCAS kernel to OpenAxiom? I think it is/was his intention that it should be Axiom-agnostic and run on any flavor. But as I said it is based rather centrally on Lisp and QuickLisp. As far as I know it has only been fully tested on FriCAS built with SBCL. >> >> Probably QT5 is a reasonable target. > > > Great! > Have you tried a QT5 build yet? Are there any known challenges in the difference between QT4 and QT5? >> >> >> > My personal development environment these days is OS X El Capitan, I can >> > have access to OpenSUSE Tumbleweed but only sporadically. I would have >> > to rely on you for OpenSUSE Leap -- I am not familiar with its >> > characteristics. >> > >> >> I can try. >> I can now report success with OpenSUSE Leap and QT4. >> >> At this point I have *both* QT4.8 and QT5 installed. Maybe that is a >> problem? > > That might be the issue. > No, that turns out not to be a problem. > ... > Yes, unfortunately, I cannot reproduce this on the opens use tumbleweed I > have access to. > Thank you very much for checking and letting me know. I think I will try a build with QT5 and see how far I get. Bill. |
From: Gabriel D. R. <gd...@in...> - 2016-02-18 07:46:09
|
On Mon, Feb 15, 2016 at 6:26 AM, Bill Page <bil...@ne...> wrote: > On 14 February 2016 at 23:29, Gabriel Dos Reis > <gd...@in...> wrote: > > > > ... The QT front-end is what I would want as replacement for the > > existing X11-based HyperDoc and Graphics component, because it is > > cross-platform (unlike X11), well-supported with high-level abstraction > > primitives for writing a good GUI. It is also now standard in the *nix > > world. > > > > However, it is at this point a work-in-progress and I would very much > like > > to see it progress at a faster pace. > > > > Yes a QT interface would be nice but (re-)implementing HyperDoc and > Graphics in QT seems to me like a lot of effort. The current fashion > trend however seems to be browser-based interfaces like Jupyter. > Yes, the QT front-end should not be seen as excluding a Jupiter front-end, and I would welcome contributions implementing the Jupiter front-end. > There is already a reasonably functional version of a Jupyter kernel > (interface) for FriCAS. This should be fairly easily adaptable to > OpenAxiom though unfortunately for the OpenAxiom development strategy > it is based rather centrally on a Lisp implementation of the kernel. > Probably a C++ implementation of a Jupyter kernel based on some of the > interface that you have already done for QT would not be too > difficult. > > > On the other hand we have the QT4 vs. QT5 split. When I wrote the > original > > skeleton, QT-4.8.something was all rage. My 2-3 years hiatus haven't > helped > > keeping pace. I would like to use QT5 as an axiomatic requirement. Is > that > > too much of a burden? > > > > Probably QT5 is a reasonable target. > Great! > > > My personal development environment these days is OS X El Capitan, I can > > have access to OpenSUSE Tumbleweed but only sporadically. I would have > to > > rely on you for OpenSUSE Leap -- I am not familiar with its > characteristics. > > > > I can try. > > >> ... > >> With this patch I was able to compile open-axiom but I did not get the > >> QT front end. Checking config.log, I noticed that it was expecting to > >> find. qmake. > > > > That is correct. Testing for QT currently relies on finding qmake (and > > moc). If that utility isn't in the path, then the configuration script > just > > assumes that QT isn't there. It can be a problem on some platforms like > > yours, but also OS X with QT5 installed via MacPorts which will put it in > > an odd place without the appropriate symlinks. On OpenSUSE > > Tumbleweed and a couple of linux platforms, it wasn't a problem. > > > > Were you able to build and run the gui on OpenSUSE Tumbleweed? > Yes (I started the implementation on a OpenSUSE Tumbleweed 3 years ago.) > > >> > >> Unfortunately qmake is only available with QT4. So I > >> installed QT4 and tried again. > >> > >> This time the compile worked and I apparently got the QT front end > >> built and installed but when I run 'open-axiom' terrible things > >> happen. > > > > Ouch! Does not sound good. > > > > At this point I have *both* QT4.8 and QT5 installed. Maybe that is a > problem? > That might be the issue. > > >> > >> My desktop becomes non-responsive and I see about three or > >> four windows with the gui open. If I cntl-alt-F1 and 'killall -9 > >> AXIOMsys', I can return to my desktop and continue. But I am not > >> longer able to start open-axiom sucessfully no matter which option I > >> choose (e.g. --no-gui still fails in the same way). > > > > Ouch, this is bizarre, and I don't think it is related to the QT > > front-end... > > If you build with QT, and you just start OpenAxiom with > > > > $ open-axiom > > > > you will NOT get the QT front-end, because it is sill a work-in-progress, > > so it is not enabled by default. > > Hmm, that is not what I observe. In my current build if I type > > $ open-axiom > > just before everything goes bad I do get what appears to be a gui > interface pop-up. In fact I get two such windows opened. Then the > desktop freezes (only mouse movement is possible). When I open a > terminal with Cntl-Alt-F1 the command > > # ps -A -f | grep open-axiom > > shows a process named 'open-axiom' and five instances of 'AXIOMsys' : > > wspage 3236 3216 0 09:17 pts/0 00:00:00 open-axiom > wspage 3239 3236 2 09:17 pts/1 00:00:01 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys > -- --role=server > wspage 3240 3236 0 09:17 pts/0 00:00:00 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/session > wspage 3241 3236 0 09:17 pts/0 00:00:00 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/clef > -f > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/command.list > -e > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/spadclient > wspage 3242 3236 0 09:17 pts/0 00:00:00 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/hypertex > wspage 3243 3236 0 09:17 pts/0 00:00:00 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/viewman > wspage 3244 3241 0 09:17 pts/2 00:00:00 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/spadclient > wspage 3246 3239 35 09:17 pts/1 00:00:22 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys > -- --role=server -- --role=server > wspage 3248 3246 1 09:17 pts/1 00:00:01 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys > -- --role=server -- --role=server -- --role=server > wspage 3250 3248 32 09:17 pts/1 00:00:20 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys > -- --role=server -- --role=server -- --role=server -- --role=server > wspage 3251 3236 0 09:17 pts/0 00:00:00 open-axiom > wspage 3253 3250 0 09:17 pts/1 00:00:00 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys > -- --role=server -- --role=server -- --role=server -- --role=server > -- --role=server > wspage 3255 3253 0 09:17 pts/1 00:00:00 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys > -- --role=server -- --role=server -- --role=server -- --role=server > -- --role=server -- --role=server > root 3307 3260 0 09:18 tty1 00:00:00 grep --color=auto > open-axiom > > Clearly something has gone wrong. > Yes, unfortunately, I cannot reproduce this on the opens use tumbleweed I have access to. > > > If you start OpenAxiom with > > > > $ open-axiom --gui > > > > then you get a QT window front-end for OpenAxiom. It works on relatively > > simple stuff, but it is not stable regarding all kinds of error handles > and > > system-level commands. > > In my case the behavior is very similar to what I described before > except I see one more gui window open but fewer open-axiom processes > running. > > wspage 3335 3216 35 09:20 pts/0 00:00:09 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/open-axiom > wspage 3337 3335 5 09:20 pts/0 00:00:01 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys > -- --role=server > wspage 3339 3337 31 09:20 pts/0 00:00:08 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys > -- --role=server -- --role=server > wspage 3341 3339 0 09:20 pts/0 00:00:00 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys > -- --role=server -- --role=server -- --role=server > wspage 3343 3341 0 09:20 pts/0 00:00:00 > > /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys > -- --role=server -- --role=server -- --role=server -- --role=server > root 3348 3260 0 09:21 tty1 00:00:00 grep --color=auto > open-axiom > > # killiall AXIOMsys > > leaves one gui window open but it is non-responsive except to Quit. > > > > >> > >> Should I expect this to work? > > > > Yes, to some degree. Certainly, I expect it NOT to freeze your system. > > Is it possible that the QT4 package itself is so old that it is causing > > problems? > > Yes it is possible. > > > From what you've described with other components such as Xt, it sounds to > > me as if this is a "unique" system setup? > > > > Yes that seems odd. How is it that this typo did not cause problems on > a build when QT was completely absent from my system? > > Bill. > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > open-axiom-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/open-axiom-devel > |
From: Bill P. <bil...@ne...> - 2016-02-15 14:26:53
|
On 14 February 2016 at 23:29, Gabriel Dos Reis <gd...@in...> wrote: > > ... The QT front-end is what I would want as replacement for the > existing X11-based HyperDoc and Graphics component, because it is > cross-platform (unlike X11), well-supported with high-level abstraction > primitives for writing a good GUI. It is also now standard in the *nix > world. > > However, it is at this point a work-in-progress and I would very much like > to see it progress at a faster pace. > Yes a QT interface would be nice but (re-)implementing HyperDoc and Graphics in QT seems to me like a lot of effort. The current fashion trend however seems to be browser-based interfaces like Jupyter. There is already a reasonably functional version of a Jupyter kernel (interface) for FriCAS. This should be fairly easily adaptable to OpenAxiom though unfortunately for the OpenAxiom development strategy it is based rather centrally on a Lisp implementation of the kernel. Probably a C++ implementation of a Jupyter kernel based on some of the interface that you have already done for QT would not be too difficult. > On the other hand we have the QT4 vs. QT5 split. When I wrote the original > skeleton, QT-4.8.something was all rage. My 2-3 years hiatus haven't helped > keeping pace. I would like to use QT5 as an axiomatic requirement. Is that > too much of a burden? > Probably QT5 is a reasonable target. > My personal development environment these days is OS X El Capitan, I can > have access to OpenSUSE Tumbleweed but only sporadically. I would have to > rely on you for OpenSUSE Leap -- I am not familiar with its characteristics. > I can try. >> ... >> With this patch I was able to compile open-axiom but I did not get the >> QT front end. Checking config.log, I noticed that it was expecting to >> find. qmake. > > That is correct. Testing for QT currently relies on finding qmake (and > moc). If that utility isn't in the path, then the configuration script just > assumes that QT isn't there. It can be a problem on some platforms like > yours, but also OS X with QT5 installed via MacPorts which will put it in > an odd place without the appropriate symlinks. On OpenSUSE > Tumbleweed and a couple of linux platforms, it wasn't a problem. > Were you able to build and run the gui on OpenSUSE Tumbleweed? >> >> Unfortunately qmake is only available with QT4. So I >> installed QT4 and tried again. >> >> This time the compile worked and I apparently got the QT front end >> built and installed but when I run 'open-axiom' terrible things >> happen. > > Ouch! Does not sound good. > At this point I have *both* QT4.8 and QT5 installed. Maybe that is a problem? >> >> My desktop becomes non-responsive and I see about three or >> four windows with the gui open. If I cntl-alt-F1 and 'killall -9 >> AXIOMsys', I can return to my desktop and continue. But I am not >> longer able to start open-axiom sucessfully no matter which option I >> choose (e.g. --no-gui still fails in the same way). > > Ouch, this is bizarre, and I don't think it is related to the QT > front-end... > If you build with QT, and you just start OpenAxiom with > > $ open-axiom > > you will NOT get the QT front-end, because it is sill a work-in-progress, > so it is not enabled by default. Hmm, that is not what I observe. In my current build if I type $ open-axiom just before everything goes bad I do get what appears to be a gui interface pop-up. In fact I get two such windows opened. Then the desktop freezes (only mouse movement is possible). When I open a terminal with Cntl-Alt-F1 the command # ps -A -f | grep open-axiom shows a process named 'open-axiom' and five instances of 'AXIOMsys' : wspage 3236 3216 0 09:17 pts/0 00:00:00 open-axiom wspage 3239 3236 2 09:17 pts/1 00:00:01 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server wspage 3240 3236 0 09:17 pts/0 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/session wspage 3241 3236 0 09:17 pts/0 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/clef -f /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/command.list -e /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/spadclient wspage 3242 3236 0 09:17 pts/0 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/hypertex wspage 3243 3236 0 09:17 pts/0 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/viewman wspage 3244 3241 0 09:17 pts/2 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/lib/spadclient wspage 3246 3239 35 09:17 pts/1 00:00:22 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server wspage 3248 3246 1 09:17 pts/1 00:00:01 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server -- --role=server wspage 3250 3248 32 09:17 pts/1 00:00:20 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server -- --role=server -- --role=server wspage 3251 3236 0 09:17 pts/0 00:00:00 open-axiom wspage 3253 3250 0 09:17 pts/1 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server -- --role=server -- --role=server -- --role=server wspage 3255 3253 0 09:17 pts/1 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server -- --role=server -- --role=server -- --role=server -- --role=server root 3307 3260 0 09:18 tty1 00:00:00 grep --color=auto open-axiom Clearly something has gone wrong. > If you start OpenAxiom with > > $ open-axiom --gui > > then you get a QT window front-end for OpenAxiom. It works on relatively > simple stuff, but it is not stable regarding all kinds of error handles and > system-level commands. In my case the behavior is very similar to what I described before except I see one more gui window open but fewer open-axiom processes running. wspage 3335 3216 35 09:20 pts/0 00:00:09 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/open-axiom wspage 3337 3335 5 09:20 pts/0 00:00:01 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server wspage 3339 3337 31 09:20 pts/0 00:00:08 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server wspage 3341 3339 0 09:20 pts/0 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server -- --role=server wspage 3343 3341 0 09:20 pts/0 00:00:00 /usr/local/lib64/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2016-02-07/bin/AXIOMsys -- --role=server -- --role=server -- --role=server -- --role=server root 3348 3260 0 09:21 tty1 00:00:00 grep --color=auto open-axiom # killiall AXIOMsys leaves one gui window open but it is non-responsive except to Quit. > >> >> Should I expect this to work? > > Yes, to some degree. Certainly, I expect it NOT to freeze your system. > Is it possible that the QT4 package itself is so old that it is causing > problems? Yes it is possible. > From what you've described with other components such as Xt, it sounds to > me as if this is a "unique" system setup? > Yes that seems odd. How is it that this typo did not cause problems on a build when QT was completely absent from my system? Bill. |
From: Gabriel D. R. <gd...@in...> - 2016-02-15 04:29:56
|
On Sun, Feb 14, 2016 at 3:59 PM, Bill Page <bil...@ne...> wrote: > Gaby, > > I was been able to compile and run open-axiom just fine until I > started to wonder about QT front end. So I decided to install QT. By > default that meant QT5 on my distribution (OpenSuse Leap). > Thanks, Bill. The QT front-end is what I would want as replacement for the existing X11-based HyperDoc and Graphics component, because it is cross-platform (unlike X11), well-supported with high-level abstraction primitives for writing a good GUI. It is also now standard in the *nix world. However, it is at this point a work-in-progress and I would very much like to see it progress at a faster pace. On the other hand we have the QT4 vs. QT5 split. When I wrote the original skeleton, QT-4.8.something was all rage. My 2-3 years hiatus haven't helped keeping pace. I would like to use QT5 as an axiomatic requirement. Is that too much of a burden? My personal development environment these days is OS X El Capitan, I can have access to OpenSUSE Tumbleweed but only sporadically. I would have to rely on you for OpenSUSE Leap -- I am not familiar with its characteristics. > Re-compiling resulted in a compiler error due to: > > diff --git a/config/open-axiom.m4 b/config/open-axiom.m4 > index 4c4a722..54a90d4 100644 > --- a/config/open-axiom.m4 > +++ b/config/open-axiom.m4 > @@ -1036,7 +1036,7 @@ AC_PATH_XTRA > ## complication right now. Will fix later. > ## But we can check for the existence of <X11/xpm.h> > ## Also check for Xt headers > -X_PRE_LIBS="-lXpm -Xt $X_PRE_LIBS" > +X_PRE_LIBS="-lXpm -lXt $X_PRE_LIBS" > AC_SUBST(X_PRE_LIBS) > > -- > Thanks for catching this -- it didn't surface on the OpenSUSE Tumbleweed platform I tested it on, for some reasons. Committed to mainline. > > With this patch I was able to compile open-axiom but I did not get the > QT front end. Checking config.log, I noticed that it was expecting to > find. qmake. That is correct. Testing for QT currently relies on finding qmake (and moc). If that utility isn't in the path, then the configuration script just assumes that QT isn't there. It can be a problem on some platforms like yours, but also OS X with QT5 installed via MacPorts which will put it in an odd place without the appropriate symlinks. On OpenSUSE Tumbleweed and a couple of linux platforms, it wasn't a problem. > Unfortunately qmake is only available with QT4. So I > installed QT4 and tried again. > > This time the compile worked and I apparently got the QT front end > built and installed but when I run 'open-axiom' terrible things > happen. Ouch! Does not sound good. > My desktop becomes non-responsive and I see about three or > four windows with the gui open. If I cntl-alt-F1 and 'killall -9 > AXIOMsys', I can return to my desktop and continue. But I am not > longer able to start open-axiom sucessfully no matter which option I > choose (e.g. --no-gui still fails in the same way). > Ouch, this is bizarre, and I don't think it is related to the QT front-end... If you build with QT, and you just start OpenAxiom with $ open-axiom you will NOT get the QT front-end, because it is sill a work-in-progress, so it is not enabled by default. If you start OpenAxiom with $ open-axiom --gui then you get a QT window front-end for OpenAxiom. It works on relatively simple stuff, but it is not stable regarding all kinds of error handles and system-level commands. > > Should I expect this to work? > Yes, to some degree. Certainly, I expect it NOT to freeze your system. Is it possible that the QT4 package itself is so old that it is causing problems? >From what you've described with other components such as Xt, it sounds to me as if this is a "unique" system setup? -- Gaby |
From: Bill P. <bil...@ne...> - 2016-02-15 00:30:37
|
Gaby, I was been able to compile and run open-axiom just fine until I started to wonder about QT front end. So I decided to install QT. By default that meant QT5 on my distribution (OpenSuse Leap). Re-compiling resulted in a compiler error due to: diff --git a/config/open-axiom.m4 b/config/open-axiom.m4 index 4c4a722..54a90d4 100644 --- a/config/open-axiom.m4 +++ b/config/open-axiom.m4 @@ -1036,7 +1036,7 @@ AC_PATH_XTRA ## complication right now. Will fix later. ## But we can check for the existence of <X11/xpm.h> ## Also check for Xt headers -X_PRE_LIBS="-lXpm -Xt $X_PRE_LIBS" +X_PRE_LIBS="-lXpm -lXt $X_PRE_LIBS" AC_SUBST(X_PRE_LIBS) -- With this patch I was able to compile open-axiom but I did not get the QT front end. Checking config.log, I noticed that it was expecting to find. qmake. Unfortunately qmake is only available with QT4. So I installed QT4 and tried again. This time the compile worked and I apparently got the QT front end built and installed but when I run 'open-axiom' terrible things happen. My desktop becomes non-responsive and I see about three or four windows with the gui open. If I cntl-alt-F1 and 'killall -9 AXIOMsys', I can return to my desktop and continue. But I am not longer able to start open-axiom sucessfully no matter which option I choose (e.g. --no-gui still fails in the same way). Should I expect this to work? Bill Page. |
From: Gabriel D. R. <gd...@in...> - 2016-02-01 10:03:10
|
Bill, See https://github.com/GabrielDosReis/open-axiom/commit/04be6d65c9bae10780f463c23a14922249c187de I don't know that your specific scenario works out of the box, since OpenAxiom requires separating build directory from source directory, hence you might run into load directory issues. If you have standalone Boot source files, that should work. -- Gaby On Sun, Jan 31, 2016 at 6:37 PM, Bill Page <bil...@ne...> wrote: > Gaby, > > Thank you very much for the explanation. I understand and appreciate > that OpenAxiom is moving away from depending on Lisp, I just did not > know quite how much! I can live with re-running make. In fact I have > been doing that and it seems that the dependencies are sufficiently > fine grained that the cycle does not take very long. This is probably > a better a methodology in any case. In my limited experience it seems > that Lisp and even Boot in FriCAS makes it a bit too easy to just hack > away at a problem. :) > > Regards, > Bill Page. > > On 31 January 2016 at 20:21, Gabriel Dos Reis > <gd...@in...> wrote: > > > > > > On Sun, Jan 31, 2016 at 5:10 PM, Bill Page <bil...@ne...> > > wrote: > >> > >> Gaby, > >> > >> I am not quite sure what you mean by "separately load it"? What I > >> have in mind is to compile a boot file to Lisp and then load it - > >> typically replacing some existing code in a running system. > > > > > > OpenAxiom has two ways of handling Boot code: > > (1) translate Boot to Lisp -- deprecated > > (2) compile Boot to machine code directly -- for more specifically a > Lisp > > FASL > > > > The preferred method is (2), as the system is minimizing lispisms and > heavy > > dependency on Lisp systems. At this moment, (1) is used only for > building > > the Boot translator itself, and is deprecated. Building the OpenAxiom > > compiler and/or interpreter is done via (2). > > > > My question was whether you wanted the ")read" command to just do (2), or > > (2) + load the resulting FASL into the running system. > > OpenAxiom applies more aggressive optimizations than other AXIOM systems. > > This means that when you modify an existing function and it was inlined > into > > some of its callers, then recompiling the boot file might not necessarily > > give you a consistent result. I don't know if this is a concern for you. > > This consistency reason was the primary reason why ")read" for Boot > script > > was removed at some point. I can put it back if you are aware of the > > consistency problem -- meaning I won't be able to help with consistency > > problems :-). > > > > > >> > >> I do this > >> quite frequently when debugging or testing some limited change in > >> FriCAS. I was surprised by the error returned in the following > >> example: > >> > >> (1) -> )read open-axiom/src/interp/format.boot > >> > >> >> System error: > >> The function BOOT::BOOT is undefined. > >> > >> Bill. > >> > >> On 31 January 2016 at 14:23, Gabriel Dos Reis > >> <gd...@in...> wrote: > >> > Hi Bill, > >> > Is the idea that you would like to change a BOOT file, compile it, and > >> > then > >> > separately load it? > >> > Or just read in the interpreted form of a BOOT file? > >> > > >> > -- Gaby > >> > > >> > > >> > On Fri, Jan 29, 2016 at 7:56 PM, Bill Page < > bil...@ne...> > >> > wrote: > >> >> > >> >> Is there a way to do this in OpenAxiom? A typical use case is when I > >> >> am debugging or experimenting with changes to the compiler or > >> >> interpreter. > >> >> > >> >> I tried: > >> >> > >> >> )read xxx.boot > >> >> > >> >> but I an error message > >> >> > >> >> (1) -> )read define.boot > >> >> > >> >> >> System error: > >> >> The function BOOT::BOOT is undefined. > >> >> > >> >> > >> >> > >> >> > ------------------------------------------------------------------------------ > >> >> Site24x7 APM Insight: Get Deep Visibility into Application > Performance > >> >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > >> >> Monitor end-to-end web transactions and take corrective actions now > >> >> Troubleshoot faster and improve end-user experience. Signup Now! > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > >> >> _______________________________________________ > >> >> open-axiom-devel mailing list > >> >> ope...@li... > >> >> https://lists.sourceforge.net/lists/listinfo/open-axiom-devel > >> > > >> > > >> > >> > >> > ------------------------------------------------------------------------------ > >> Site24x7 APM Insight: Get Deep Visibility into Application Performance > >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > >> Monitor end-to-end web transactions and take corrective actions now > >> Troubleshoot faster and improve end-user experience. Signup Now! > >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > >> _______________________________________________ > >> open-axiom-devel mailing list > >> ope...@li... > >> https://lists.sourceforge.net/lists/listinfo/open-axiom-devel > > > > > |
From: Bill P. <bil...@ne...> - 2016-02-01 02:37:42
|
Gaby, Thank you very much for the explanation. I understand and appreciate that OpenAxiom is moving away from depending on Lisp, I just did not know quite how much! I can live with re-running make. In fact I have been doing that and it seems that the dependencies are sufficiently fine grained that the cycle does not take very long. This is probably a better a methodology in any case. In my limited experience it seems that Lisp and even Boot in FriCAS makes it a bit too easy to just hack away at a problem. :) Regards, Bill Page. On 31 January 2016 at 20:21, Gabriel Dos Reis <gd...@in...> wrote: > > > On Sun, Jan 31, 2016 at 5:10 PM, Bill Page <bil...@ne...> > wrote: >> >> Gaby, >> >> I am not quite sure what you mean by "separately load it"? What I >> have in mind is to compile a boot file to Lisp and then load it - >> typically replacing some existing code in a running system. > > > OpenAxiom has two ways of handling Boot code: > (1) translate Boot to Lisp -- deprecated > (2) compile Boot to machine code directly -- for more specifically a Lisp > FASL > > The preferred method is (2), as the system is minimizing lispisms and heavy > dependency on Lisp systems. At this moment, (1) is used only for building > the Boot translator itself, and is deprecated. Building the OpenAxiom > compiler and/or interpreter is done via (2). > > My question was whether you wanted the ")read" command to just do (2), or > (2) + load the resulting FASL into the running system. > OpenAxiom applies more aggressive optimizations than other AXIOM systems. > This means that when you modify an existing function and it was inlined into > some of its callers, then recompiling the boot file might not necessarily > give you a consistent result. I don't know if this is a concern for you. > This consistency reason was the primary reason why ")read" for Boot script > was removed at some point. I can put it back if you are aware of the > consistency problem -- meaning I won't be able to help with consistency > problems :-). > > >> >> I do this >> quite frequently when debugging or testing some limited change in >> FriCAS. I was surprised by the error returned in the following >> example: >> >> (1) -> )read open-axiom/src/interp/format.boot >> >> >> System error: >> The function BOOT::BOOT is undefined. >> >> Bill. >> >> On 31 January 2016 at 14:23, Gabriel Dos Reis >> <gd...@in...> wrote: >> > Hi Bill, >> > Is the idea that you would like to change a BOOT file, compile it, and >> > then >> > separately load it? >> > Or just read in the interpreted form of a BOOT file? >> > >> > -- Gaby >> > >> > >> > On Fri, Jan 29, 2016 at 7:56 PM, Bill Page <bil...@ne...> >> > wrote: >> >> >> >> Is there a way to do this in OpenAxiom? A typical use case is when I >> >> am debugging or experimenting with changes to the compiler or >> >> interpreter. >> >> >> >> I tried: >> >> >> >> )read xxx.boot >> >> >> >> but I an error message >> >> >> >> (1) -> )read define.boot >> >> >> >> >> System error: >> >> The function BOOT::BOOT is undefined. >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> >> Monitor end-to-end web transactions and take corrective actions now >> >> Troubleshoot faster and improve end-user experience. Signup Now! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 >> >> _______________________________________________ >> >> open-axiom-devel mailing list >> >> ope...@li... >> >> https://lists.sourceforge.net/lists/listinfo/open-axiom-devel >> > >> > >> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 >> _______________________________________________ >> open-axiom-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/open-axiom-devel > > |
From: Gabriel D. R. <gd...@in...> - 2016-02-01 01:21:14
|
On Sun, Jan 31, 2016 at 5:10 PM, Bill Page <bil...@ne...> wrote: > Gaby, > > I am not quite sure what you mean by "separately load it"? What I > have in mind is to compile a boot file to Lisp and then load it - > typically replacing some existing code in a running system. OpenAxiom has two ways of handling Boot code: (1) translate Boot to Lisp -- deprecated (2) compile Boot to machine code directly -- for more specifically a Lisp FASL The preferred method is (2), as the system is minimizing lispisms and heavy dependency on Lisp systems. At this moment, (1) is used only for building the Boot translator itself, and is deprecated. Building the OpenAxiom compiler and/or interpreter is done via (2). My question was whether you wanted the ")read" command to just do (2), or (2) + load the resulting FASL into the running system. OpenAxiom applies more aggressive optimizations than other AXIOM systems. This means that when you modify an existing function and it was inlined into some of its callers, then recompiling the boot file might not necessarily give you a consistent result. I don't know if this is a concern for you. This consistency reason was the primary reason why ")read" for Boot script was removed at some point. I can put it back if you are aware of the consistency problem -- meaning I won't be able to help with consistency problems :-). > I do this > quite frequently when debugging or testing some limited change in > FriCAS. I was surprised by the error returned in the following > example: > > (1) -> )read open-axiom/src/interp/format.boot > > >> System error: > The function BOOT::BOOT is undefined. > > Bill. > > On 31 January 2016 at 14:23, Gabriel Dos Reis > <gd...@in...> wrote: > > Hi Bill, > > Is the idea that you would like to change a BOOT file, compile it, and > then > > separately load it? > > Or just read in the interpreted form of a BOOT file? > > > > -- Gaby > > > > > > On Fri, Jan 29, 2016 at 7:56 PM, Bill Page <bil...@ne...> > > wrote: > >> > >> Is there a way to do this in OpenAxiom? A typical use case is when I > >> am debugging or experimenting with changes to the compiler or > >> interpreter. > >> > >> I tried: > >> > >> )read xxx.boot > >> > >> but I an error message > >> > >> (1) -> )read define.boot > >> > >> >> System error: > >> The function BOOT::BOOT is undefined. > >> > >> > >> > ------------------------------------------------------------------------------ > >> Site24x7 APM Insight: Get Deep Visibility into Application Performance > >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > >> Monitor end-to-end web transactions and take corrective actions now > >> Troubleshoot faster and improve end-user experience. Signup Now! > >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > >> _______________________________________________ > >> open-axiom-devel mailing list > >> ope...@li... > >> https://lists.sourceforge.net/lists/listinfo/open-axiom-devel > > > > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > open-axiom-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/open-axiom-devel > |
From: Bill P. <bil...@ne...> - 2016-02-01 01:10:16
|
Gaby, I am not quite sure what you mean by "separately load it"? What I have in mind is to compile a boot file to Lisp and then load it - typically replacing some existing code in a running system. I do this quite frequently when debugging or testing some limited change in FriCAS. I was surprised by the error returned in the following example: (1) -> )read open-axiom/src/interp/format.boot >> System error: The function BOOT::BOOT is undefined. Bill. On 31 January 2016 at 14:23, Gabriel Dos Reis <gd...@in...> wrote: > Hi Bill, > Is the idea that you would like to change a BOOT file, compile it, and then > separately load it? > Or just read in the interpreted form of a BOOT file? > > -- Gaby > > > On Fri, Jan 29, 2016 at 7:56 PM, Bill Page <bil...@ne...> > wrote: >> >> Is there a way to do this in OpenAxiom? A typical use case is when I >> am debugging or experimenting with changes to the compiler or >> interpreter. >> >> I tried: >> >> )read xxx.boot >> >> but I an error message >> >> (1) -> )read define.boot >> >> >> System error: >> The function BOOT::BOOT is undefined. >> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 >> _______________________________________________ >> open-axiom-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/open-axiom-devel > > |