There is long time since the last release, I think that we
should have a new one. In the last few months my main developement
effort was on internal restructuring (cleanups) which in
principle should be invisible to users. But we also have
new features, notably Aldor interface. Current svn version
should be quite a bit faster than fricas-1.0.3. We have
also a bunch of bug fixes.
Current situation with Lisp implementations is as follows:
- With recent gcl snapshot and new build instructions hopefully
we should be able to build gcl on all Linux versions. AFAICS
on Windows one still has to use obsolete Mingw version.
- 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. Now this problem is fixed. Closure CL has slow
bignums, but otherwise is quite fast. Given recent developements,
we can hope that Closure CL will give us high performance Lisp
running well on all major platforms.
- Currently ecl gives us similar performance to gcl. There is one
problem: ')fin' does not work. Also, ecl based FriCAS sometimes
could segfault when quitting -- AFAIK CVS version of ecl contains
fix for this problem. ecl starts us slower than other Lisp
implementations. However, main reason for slow startup was
garbage collection when loading compiled Lisp files -- hopefully
futute ecl version will skip this garbage collection giving much
faster startup. Version which skips garbage collection needs 0.4s
to startup on my machine -- which is not exactly fast but should be
quite acceptable (compared to 1.5-6s for previous versions). Given
that ecl is supposed to build on all platforms that we support,
it may give us best combination of performance and portability.
- In most benchmarks that I run sbcl seem to be quite a bit faster
than other Lisp implementations.
- Theoretically clisp is very portable, but it seems that in practice
building it is problematic. In particular it seems that some
people disable dynamic FFI in order to build clisp. Current svn
FriCAS will fail to build on clisp without dynamic FFI. For
Sage I did a patch that allows building without dynamic FFI
at const of disabling some functionality (currently graphics
and hyperdoc). I wonder if I should include this patch in
the repository (I would prefer people to build clisp with
dynamic FFI included).
I still hope to fix some bugs before release. A few comments
about bugs:
434 -- I can not reproduce the issue, for me line is drawn OK.
433 -- The core issue is that comunication protocol between
AXIOMsys and viewport requires perfect synchronization,
once two ends go out of sync things stop working. This
problem requires changing protocol and rewritting communication
routines, clearly not a quick job. We may try to fix
just the specific problem (avoiding getting out of sync),
I am not sure if thaer is quick fix for this.
122 -- I have now narrowed down the problem to resolveTTeq:
)lisp (|resolveTTEq| '(|UnivariatePuiseuxSeries| (|Expression| (|Integer|)) |x|
((0 . 0) 0 . 1)) '(|Float|))
Value = (|UnivariatePuiseuxSeries| (|Expression| (|Float|)) |x| ((0 . 0) 0 . 1))
If one looks how things are represented one sees that the third argument is
has old representation (corresponding to Expression Integer) but is
now treated as Expression Float. More preciesly, the constructTowerT
routine, transforms type arguments but leaves non-type arguments
as is -- this is clearly wrong when type of non-type argument is
modified. It would be easy to correct constructTowerT in specific
cases (like the UnivariatePuiseuxSeries), but is looks harder
to do fix it in general case -- I am not sure if I manage this for
the release.
301 -- this is due to InputForm lacking package call. Finding out
where this form is generated requires more work.
23 -- while the bug is fixed we still should do some releated cleanups
In particlar, for release I would probably prefer minimal cleanup
(which should be pretty safe) and I would rather postpone bigger
cleanup after release.
I am affraid that the new unparsing routines still have a few
bugs. Also, I think that we should fix/implement a few more
convertions to InputForm.
Concerining release, I think it would be good to provide some
bianaries. I can create tarballs for i386 and amd64 Linux --
I think that such tarballs should work on most Linux distributions.
Given sbcl performance I think that such tarballs should be sbcl
based. I am not sure about other package forms: distribution
specific packages are nicer than generic tarball, but given that
there are several different distributions it looks like too much
work for too little effect.
It would be nice to have binaries for other platforms, but currently
I can not make them -- if somebody else would provide them I will
add them to download page.
--
Waldek Hebisch
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
