> It seems that you abuse the testing framwork.
I confess. Nevertheless test_dg1 is a first step to self-improvement.
The other two were started long ago, but rewriting them is in the pipeline.
> Namely, testing
> framework is supposed to show you failning test. With your
> appreach the report w
oldk1331 wrote:
>
> Hi Waldek, what's your plan about the integration bug in FSRED(pfo.spad)?
Some solution is needed. I stil hope that we can do proper solution,
that is implement re-run with new random numbers taken from bigger
set.
--
Waldek Hebisch
--
You re
Hi Waldek, what's your plan about the integration bug in FSRED(pfo.spad)?
--
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 fricas-devel+unsubs
Kurt Pagani wrote:
>
> Eventually I've completed some packages ;)
> The files are attached for general review and are also available here:
> https://github.com/nilqed/fricas_input/tree/master/deploy
>
Interesting packages, thanks.
> Tests:
>
> )read test_dform
> )read test_scmplx
> )read
Great, thank you. Change/extend as much as you like, I'd be really grateful
if you could have a closer look at it.
Kurt
On Monday, 30 January 2017 04:07:41 UTC+1, oldk1331 wrote:
>
> Hello Kurt, I'm also interested in differential forms and differential
> geometry,
> and I looked into dform.s
Hello Kurt, I'm also interested in differential forms and differential geometry,
and I looked into dform.spad/pdf a bit, I make some changes to example
code. Also a word of advice: you can cleanup trailing white spaces in these
files.
diff --git a/deploy/dform.spad b/deploy/dform.spad
index 4ebe1
On Monday 01 Nov 2010 19:49:43 Waldek Hebisch wrote:
> Thanks for update. ATM I am having problems bootstrapping with
> scene.spad.pamphlet included, once I resolve this I will commit.
Waldek,
It will be good to have this in the next release of FriCAS, thanks.
Its very useful to get feedback an
>
> On Thursday 28 Oct 2010 18:21:43 Waldek Hebisch wrote:
> > Looks interesting. However ATM I am not able to run any example.
> > In the text you wrote about SPoint2, etc, but there is no such
> > domain...
>
> Waldek,
>
> I have corrected:
> scene.spad.pamphlet
>
Thanks for update. ATM I a
On Thursday 28 Oct 2010 18:21:43 Waldek Hebisch wrote:
> Looks interesting. However ATM I am not able to run any example.
> In the text you wrote about SPoint2, etc, but there is no such
> domain...
Waldek,
I have corrected:
scene.spad.pamphlet
Which is available here:
http://github.com/martinb
On Thursday 28 Oct 2010 18:21:43 Waldek Hebisch wrote:
> Looks interesting. However ATM I am not able to run any example.
> In the text you wrote about SPoint2, etc, but there is no such
> domain...
Waldek,
Sorry, I changed SPoint2 to SCartesian(2) and I must have missed some
occurrences of SPoi
>
> On Thursday 21 Oct 2010 17:10:38 Waldek Hebisch wrote:
> > We also have a bunch of bug fixes. Given that I would like to
> > make a new release in about two weeks.
>
> Waldek,
>
> Would you be interested in including the graphics framework which is
> in this file:
>
> scene.spad.pamphlet
>
On Thursday 21 Oct 2010 17:10:38 Waldek Hebisch wrote:
> We also have a bunch of bug fixes. Given that I would like to
> make a new release in about two weeks.
Waldek,
Would you be interested in including the graphics framework which is
in this file:
scene.spad.pamphlet
Which is available here
I am more focused on consistency since working with Sage, not because
Sage is so consistent, but rather the opposite. ;-)
Because FriCAS/Axiom attempts to strongly encourages generic
programming by polymorphism I think it is important to try to get the
name right the first time or at least as soo
> It seemse that we could just use divide as name of operation.
> Then we will re-use implementation from FreeMonoid.
I came to the same conclusion and was about to propose it.
We should rather change this line
"div": (%, %) -> Union(Record(lm: %, rm: %), "failed")
in the OrderedFreeM
Bill Page wrote:
>
> Waldek,
>
> On Thu, Oct 15, 2009 at 4:40 PM, Waldek Hebisch
> wrote:
> >
> > Bill Page wrote:
> >> Waldek,
> >>
> >> I have a few more patches that I would like to get into FriCAS before
> >> the next release but really none of them are "critical". ?Here's one
> >> for XPOL
Waldek,
On Thu, Oct 15, 2009 at 4:40 PM, Waldek Hebisch
wrote:
>
> Bill Page wrote:
>> Waldek,
>>
>> I have a few more patches that I would like to get into FriCAS before
>> the next release but really none of them are "critical". Here's one
>> for XPOLY. It adds a couple of missing functions.
Bill Page wrote:
> Waldek,
>
> I have a few more patches that I would like to get into FriCAS before
> the next release but really none of them are "critical". Here's one
> for XPOLY. It adds a couple of missing functions. I first mentioned
> this patch here:
>
> http://lists.gnu.org/archive/h
Note correction to wiki page link referred to in the email archive:
http://axiom-wiki.newsynthesis.org/SandBoxNoncommutativePolynomials
On Thu, Oct 15, 2009 at 3:36 PM, Bill Page wrote:
> Waldek,
>
> I have a few more patches that I would like to get into FriCAS before
> the next release but
Waldek,
I have a few more patches that I would like to get into FriCAS before
the next release but really none of them are "critical". Here's one
for XPOLY. It adds a couple of missing functions. I first mentioned
this patch here:
http://lists.gnu.org/archive/html/axiom-math/2006-03/msg3.ht
Martin Rubey wrote:
>
> Waldek Hebisch writes:
>
> > Major changes planned for next release are done. The only "release
> > critical" code patch pending is disabling Aldor interface.
> >
> > There is still time for some smaller changes and we need to update
> > documentation, but in the next w
Waldek Hebisch writes:
> Major changes planned for next release are done. The only "release
> critical" code patch pending is disabling Aldor interface.
>
> There is still time for some smaller changes and we need to update
> documentation, but in the next week we should have release.
I would
On 10/15/2009 03:57 AM, Waldek Hebisch wrote:
> Major changes planned for next release are done. The only "release
> critical" code patch pending is disabling Aldor interface.
My first glance gave me a good impression. I'll check more carefully
tonight.
> There is still time for some smaller c
>
> I will create a release branch in few hours. Before branch is
> created please do not commit anything to trunk without
> consultation with me.
>
I have created release branch. Developement on trunk can go
as usual.
--
Waldek Hebisch
hebi...@math.uni.wroc.pl
I will create a release branch in few hours. Before branch is
created please do not commit anything to trunk without
consultation with me.
--
Waldek Hebisch
hebi...@math.uni.wroc.pl
--~--~-~--~~~---~--~~
You received this message b
I wrote:
>
> I have now created release branch. I am now doing final testing.
> Unless some serious problems show up the release will be identical
> to current release branch.
Before branching I forgot to regenerate interp-proclaims.lisp,
so I just did it. Hopefully this was the last change.
I wrote:
>
> I plan a new release in few days.
I have now created release branch. I am now doing final testing.
Unless some serious problems show up the release will be identical
to current release branch. After testing I will prepare Linux
binaries. I encourage everybody with spare cycles to
Martin Rubey wrote:
>
> Waldek Hebisch writes:
>
> > I plan a new release in few days. There is long time from
> > 1.0.5, we have significant internal changes and a few
> > improvements and bug fixes. I think that we should merge
> > new-lambda shortly after new release -- new-lambda does not
Waldek Hebisch writes:
> I plan a new release in few days. There is long time from
> 1.0.5, we have significant internal changes and a few
> improvements and bug fixes. I think that we should merge
> new-lambda shortly after new release -- new-lambda does not
> add new user visible features bu
Ralf Hemmecke wrote:
>
> Hi Waldek,
>
> > I think that we should merge
> > new-lambda shortly after new release -- new-lambda does not
> > add new user visible features but potentially may add new
> > bugs.
>
> I would be more in favour of merging new-lambda, when all the conversion
> is done
Hi Waldek,
> I think that we should merge
> new-lambda shortly after new release -- new-lambda does not
> add new user visible features but potentially may add new
> bugs.
I would be more in favour of merging new-lambda, when all the conversion
is done on the branch. There are still a lot of ou
Just downloaded trunk, FriCAS compiled like a charm with algebra
optimization (amd64 Debian testing with SBCL 1.0.23).
This is clearer now, thanks!
Greg
PS : in the note of the algebra optimization section of the INSTALL file
there is a typo : Ratinale instead of Rationale
Le samedi 31 janvier
Gregory Vanuxem wrote:
>
> This is a good news. May I suggest that you add some documentation
> about the optimization option at configure time (--with-algebra-optimization)
> This option is relatively difficult to understand I find.
>
For 1.0.5 I have added a section about algebra optiomization
Martin Rubey wrote:
>
> How about the patches to have drawing of badly behaved functions work on sbcl?
>
> (actually, I see that I have two slightly differing sets of patches on my
> computer now, I'm attaching the more plausible one)
>
A I wrote, I feel that this patch just hides errors. We
How about the patches to have drawing of badly behaved functions work on sbcl?
(actually, I see that I have two slightly differing sets of patches on my
computer now, I'm attaching the more plausible one)
Martin
Index: src/algebra/clip.spad.pamphlet
=
Waldek Hebisch writes:
> I think it is time for new release. We are now at revision 488
> which means 40 revisions form the 1.0.4. This is not much but
> we have several bug fixes and new functionality. ATM my aim is
> to do release at end of next week.
Great! I'll try to fill in the missin
Hello Waldek, *
Le vendredi 16 janvier 2009 à 19:34 +0100, Waldek Hebisch a écrit :
>
> I think it is time for new release. We are now at revision 488
> which means 40 revisions form the 1.0.4. This is not much
> but we have several bug fixes and new functionality. ATM
> my aim is to do relea
Francois Maltey <[EMAIL PROTECTED]> writes:
> Hi,
> >> Somebody should check (re-check ?) branch cuts and singularities with this
> >> patch.
> >>
> >
> > (for convenience, I include the patch below)
> >
> > I guess the right place to check branch cuts and singularities is in
> > src/input/e
Hi,
>> Somebody should check (re-check ?) branch cuts and singularities with this
>> patch.
>>
>
> (for convenience, I include the patch below)
>
> I guess the right place to check branch cuts and singularities is in
> src/input/elemnum.input. I looked at the common lisp hyperspec, the
> de
Waldek, the branch cuts in the numeric code seem to differ from the HyperSpec.
I know now how to implement unit tests, but I need to know which conventions we
want to follow. I believe that the Common Lisp HyperSpec is a good choice,
because it's a standard, and because Common Lisp is our underly
If we take the HyperSpec as definition, we have a problem. Actually, we have a
problem in any case:
(1) -> )lisp (asin (complex -3.0 -0.1))
Value = #C(-1.535458462580241 -1.763409543539737)
(1) -> )lisp (asin (complex -3.0 0.0))
Value = #C(-1.5707963267948966 1.762747174039086)
(1) -> )lisp (asi
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> > * the patch by Francois Maltey for asin, acos, etc.
> >
>
> Somebody should check (re-check ?) branch cuts and singularities with this
> patch.
(for convenience, I include the patch below)
I guess the right place to check branch cuts and singular
Martin Rubey wrote:
>
> One other thing: In vmlisp.lisp we have
>
> (defun EBCDIC (x) (int-char x))
>
> open-axiom has
>
> (defun EBCDIC (x) (code-char x))
>
> since int-char is undefined.
>
I looked once at EBCDIC, and IIRC my conclusion was that uses of
EBCDIC are potential bugs. I left
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> Martin Rubey wrote:
> >
> > Waldek Hebisch <[EMAIL PROTECTED]> writes:
> >
> > >
> > > I mean rather obscure and low-level Spad feature: if you wrote
> > > x : T inside expression it meant that the compiler x should
> > > treat x as having type T.
Martin Rubey wrote:
>
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> >
> > I mean rather obscure and low-level Spad feature: if you wrote
> > x : T inside expression it meant that the compiler x should
> > treat x as having type T. Similar to pretend, but perfomed less
> > checks and did not
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> Martin Rubey wrote:
> >
> >
> > - removed support for attributes (replaced by empty categories) and
> > colon convertions in Spad code
> >
> > I think you meant - actually, I do not know what you meant with
> >
> > colon convertions in Spad co
Martin Rubey wrote:
>
>
> - removed support for attributes (replaced by empty categories) and
> colon convertions in Spad code
>
> I think you meant - actually, I do not know what you meant with
>
> colon convertions in Spad code
>
>
> perhaps "coercions"? But what would "colon" be the
- removed support for attributes (replaced by empty categories) and
colon convertions in Spad code
I think you meant - actually, I do not know what you meant with
colon convertions in Spad code
perhaps "coercions"? But what would "colon" be then?
Martin
--~--~-~--~~-
Martin Rubey wrote:
>
> Martin Rubey <[EMAIL PROTECTED]> writes:
>
> > One other thing: In vmlisp.lisp we have
>
> Yet another thing:
>
> for the creation of the deb package I noticed that I had to change mk_deb. I
> think that presea is gone, isn't it?
>
presea is fine, simply there shoul
Martin Rubey <[EMAIL PROTECTED]> writes:
> One other thing: In vmlisp.lisp we have
Yet another thing:
for the creation of the deb package I noticed that I had to change mk_deb. I
think that presea is gone, isn't it?
Finally, should we try to get FriCAS into Cygwin? The main problem (to get
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> Martin Rubey wrote:
> >
> > Waldek,
> >
> > didn't you want to release? Is there something missing?
> >
>
> We will have release, I was just pretty busy last few days so there
> is a delay.
Great. Actually, given the amount of work you usually p
Martin Rubey wrote:
>
> Waldek,
>
> didn't you want to release? Is there something missing?
>
We will have release, I was just pretty busy last few days so there
is a delay.
> I'd really like to get some patches finalised and into trunk,
Sorry, I forgot to say: since we have release branch
Waldek,
didn't you want to release? Is there something missing?
I'd really like to get some patches finalised and into trunk, lest I loose them
on my laptop:
* patches to plot with non gcl
* patches to packageCall and InputForms for Segment
* patches to isExpt and operators (needs discussion
I've just succeeded to build fricas+aldor on a debian etch 64 bit box.
Compilation worked smoothly and the result seems to work.
Ralf
~/scratch>fricas
GCL (GNU Common Lisp) 2.6.7 CLtL1Oct 29 2006 20:31:33
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed
Bill Page wrote:
>
> On Fri, Oct 24, 2008 at 7:08 PM, Waldek Hebisch wrote:
> >>
> > I am not sure if 'fixedPointExquo' is better -- it looks that 'exquo'
> > performs the same computation, but when given nontrivial zero
> > series 'fixedPointExquo' will indefinitly try find nonzero coefficient,
On Fri, Oct 24, 2008 at 7:08 PM, Waldek Hebisch wrote:
>
> Bill Page wrote:
>> ...
>> It looks to me like just a better version of the 'exquo' that is
>> exported by 'StreamTaylorSeriesOperations' and called by 'exquo'
>> in TaylorSeries (which is already exposed in the interpreter). The
>> commen
Bill Page wrote:
>
> On Wed, Oct 22, 2008 at 11:56 AM, Martin Rubey wrote:
> >
> > Bill Page writes:
> >
> >> If it is internal, why is it exported? Perhaps some other aspect of
> >> this design needs to be reconsidered. Maybe 'fixedPointExquo" is
> >> being defined in the wrong place?
> >
> > We
Martin Ruber wrote:
>
> However, I meanwhile have what I believe is a sensible patch for some related
> stuff. I modify packageCall (currently unused), to take as second argument a
> list of InputForm's, corresponding to the arguments of the function.
>
The patch looks reasonable. However, whi
On Wed, Oct 22, 2008 at 11:56 AM, Martin Rubey wrote:
>
> Bill Page writes:
>
>> If it is internal, why is it exported? Perhaps some other aspect of
>> this design needs to be reconsidered. Maybe 'fixedPointExquo" is
>> being defined in the wrong place?
>
> Well, I want to say that it's probably n
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> Martin Rubey wrote:
> > Oh, I see now. The right design is to simply change
> >
> > MakeFunction(S: ConvertibleTo InputForm): Exports == Implementation where
> >
> > to
> >
> > MakeFunction(S: InputForm): Exports == Implementation where
> >
> > ri
Martin Rubey wrote:
>
> I did a tiny bit of digging. Results:
>
> * Maybe every domain (either of category Type, or BasicType) should have
> CoercibleTo(%), and ConvertibleTo should have CoercibleTo. There are two
> possible reasons against it:
>
> 1) it might not work (after all, it's
Martin Rubey wrote:
> Oh, I see now. The right design is to simply change
>
> MakeFunction(S: ConvertibleTo InputForm): Exports == Implementation where
>
> to
>
> MakeFunction(S: InputForm): Exports == Implementation where
>
> right?
>
InputForm is a domain, so this will work differently th
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> I still haven't heard about your use case, so I can only guess.
Sorry, the use case is not quite clear to me either. I was wondering about how
to fix seriesSolve, which uses a hack to get "fixedPointExquo" called. This
hack fails if fixedPointExquo i
"Bill Page" <[EMAIL PROTECTED]> writes:
> > I looked at this again. First, to answer Bill's question: "why isn't
> > UnivariateTaylorSeriesODESolver exposed?" These are really
> > internal functions. I think as an intermediate measure, exposing
> > makes sense. But really, we should explicite
I still haven't heard about your use case, so I can only guess.
I think you are not right.
If I look at MakeFunction then I see
function(s:S, name:SY, args:List SY) ==
interpret function(convert s, args, name)$InputForm
name
so if S is Inputform then I would expect that simpl
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> > * Maybe every domain (either of category Type, or BasicType) should have
> > CoercibleTo(%), and ConvertibleTo should have CoercibleTo. There are two
> > possible reasons against it:
> >
> > 1) it might not work (after all, it's somehow recurs
On Wed, Oct 22, 2008 at 2:07 AM, Martin Rubey wrote:
>
> Waldek Hebisch writes:
>
>> I wrote:
>> >
>> > Martin Rubey wrote:
>> > >
>> > > Waldek Hebisch writes:
>> > >
>> > > > 301 -- this is due to InputForm lacking package call. Finding
>> > > > out where this form is generated requires more wo
> * Maybe every domain (either of category Type, or BasicType) should have
> CoercibleTo(%), and ConvertibleTo should have CoercibleTo. There are two
> possible reasons against it:
>
> 1) it might not work (after all, it's somehow recursive)
>
> 2) it might slow down the system.
It sho
I did a tiny bit of digging. Results:
* Maybe every domain (either of category Type, or BasicType) should have
CoercibleTo(%), and ConvertibleTo should have CoercibleTo. There are two
possible reasons against it:
1) it might not work (after all, it's somehow recursive)
2) it might slo
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> I wrote:
> >
> > Martin Rubey wrote:
> > >
> > > Waldek Hebisch <[EMAIL PROTECTED]> writes:
> > >
> > > > 301 -- this is due to InputForm lacking package call. Finding out
> > > > where this form is generated requires more work.
I looked at this a
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> I wrote:
> >
> > Martin Rubey wrote:
> > >
> > > Waldek Hebisch <[EMAIL PROTECTED]> writes:
> > >
> > > > 301 -- this is due to InputForm lacking package call. Finding out
> > > > where this form is generated requires more work.
> > >
> > > Hm,
I wrote:
>
> Martin Rubey wrote:
> >
> > Waldek Hebisch <[EMAIL PROTECTED]> writes:
> >
> > > 301 -- this is due to InputForm lacking package call. Finding out
> > > where this form is generated requires more work.
> >
> > Hm, I thought I sent a partial fix or at least improvement at some p
Maybe Martin rather meant something like "sage -upgrade".
That would sound like a great idea if no compilation is involved, but I
don't think FriCAS currently has the manpower to provide binaries for
any possible major platform.
Maybe it makes sense to keep the sage fricas.spkg alway up-to-date
Martin Rubey wrote:
> YES. By the way: wouldn't it make sense to keep the svn files, so users can
> type svn up and get newer versions? It's not 100% reliable, but should work
> most of the time.
>
I do not think it is a good idea:
1) .svn subdirectories significantly increase tarball size
2)
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> > That's actually what I did. So, maybe keep it that way and install
> > fricas*.el
> > into
> >
> > /usr/lib/fricas/
> >
> > and do
> >
> > (setq load-path (cons (quote "/usr/lib/fricas/emacs") load-path))
> >
> > in efricas.
>
> Könntest Du
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> > (is there any reason to have lib/fricas/target/i686-pc-linux/ in the
> > prefix?)
>
> There is no such path in the prefix. Remember, I used "./configure
> --prefix=~/software". That fricas is so deeply installed under a
> "target" directory, is ce
> (is there any reason to have lib/fricas/target/i686-pc-linux/ in the prefix?)
There is no such path in the prefix. Remember, I used "./configure
--prefix=~/software". That fricas is so deeply installed under a
"target" directory, is certainly a leftover of the original Axiom build
procedure.
> That's actually what I did. So, maybe keep it that way and install fricas*.el
> into
>
> /usr/lib/fricas/
>
> and do
>
> (setq load-path (cons (quote "/usr/lib/fricas/emacs") load-path))
>
> in efricas.
Könntest Du mir da vielleicht helfen? Ich bin kein elisp Experte und
wenn Du schon
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> What you have communicated so far let's me think that the fricas code
> simply lives on some disk partition that is mounted on the client. Why
> is the server relevant at all?
It provides the disk partition for 30 clients, so all clients have the same
> Sorry, I miscommunicated: the server *only* serves as memory for the clients.
> I.e., the clients fetch the binary from the server, that's all.
I don't understand at all this kind of architecture. Are you speaking of
thin-clients here or why must fricas be moved to the server if at
runtime th
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> > Furthermore, make install should not simply overwrite a present fricas
> > installation, but rather ask, don't you think?
> >
>
> That would be unusual.
OK.
> > > Concerining release, I think it would be good to provide some bianaries.
> > > I
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> Hi Martin,
>
> On 10/17/2008 08:43 PM, Martin Rubey wrote:
> > Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> >
> >>> The procedure here worked as follows:
> >>> * compile (as ordinary user) on a user machine
> >>> * copy it to a server machine (which ha
Martin Rubey wrote:
>
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> > - Closure CL has now experimental version for 32-bit Linux (64-bit
> > Linux was supported for long time) and for Windows. There was
> > a glitch in the way Closure CL was installed -- it required presence
> > of bui
Hi Martin,
On 10/17/2008 08:43 PM, Martin Rubey wrote:
> Ralf Hemmecke <[EMAIL PROTECTED]> writes:
>
>>> The procedure here worked as follows:
>>> * compile (as ordinary user) on a user machine
>>> * copy it to a server machine (which has different architecture) with
>>> special
>>> priviledg
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> > The procedure here worked as follows:
>
> > * compile (as ordinary user) on a user machine
> > * copy it to a server machine (which has different architecture) with
> > special
> > priviledges (I'm not sure whether root was enough here)
> > * make
> The procedure here worked as follows:
> * compile (as ordinary user) on a user machine
> * copy it to a server machine (which has different architecture) with special
> priviledges (I'm not sure whether root was enough here)
> * make install on the server machine.
Sounds not like a big probl
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> On 10/17/2008 09:31 AM, Martin Rubey wrote:
> > A remotely similar problem: make install (at least with ecl) requires
> > presence
> > of *source* tree, which posed some problems here in Hannover.
>
> I don't know for sure, but I tend to see this as a
On 10/17/2008 09:31 AM, Martin Rubey wrote:
> A remotely similar problem: make install (at least with ecl) requires presence
> of *source* tree, which posed some problems here in Hannover.
I don't know for sure, but I tend to see this as a bug. But thinking
twice... you usually type "./configure
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> - Closure CL has now experimental version for 32-bit Linux (64-bit
> Linux was supported for long time) and for Windows. There was
> a glitch in the way Closure CL was installed -- it required presence
> of build tree.
A remotely similar prob
88 matches
Mail list logo
