Greetings, and please excuse the delayed reply.
Waldek Hebisch <[email protected]> writes:
> BTW: I have added a test for file operations and currently there
> are several failures in GCL based FriCAS. One issue is that
> FriCAS creates specialised array with element type '(UNSIGNED-BYTE 32)'.
> GCL reports element type of the array as 'FIXNUM' and type
> tests that FriCAS uses consider 'FIXNUM' as different from
> '(UNSIGNED-BYTE 32)'. When reading from files FriCAS needs to
> re-create array type, so currently writing of such arrays
> fails. I can add 'FIXNUM' to the list of array element types
> considerd by FriCAS, but I a bit worried if this does not lead
> to wrong code somewhere else: FriCAS type machinery "knows"
> that element type is '(UNSIGNED-BYTE 32)' and uses this type
> for in declarations passed to Lisp. If I re-create the array
> with element type 'FIXNUM', then formally types do not match
> and there is potential for miscompilation. So, the question
> is if specialized array having 'FIXNUM' as element type
> is the same as specialized array having '(UNSIGNED-BYTE 32)'
> as element type.
In GCL 2.6.14, the array element types created when passing
:element-type '(unsigned-byte 32) or :element-type 'fixnum to make-array
are the same, and are indistinguishable if all the elements are.
In 2.7.0, there is a separate type for the former. In general, in ANSI
cl, implementations must "upgrade" element-types to a fixed lattice
set, so you really only get the result of (upgrade-array-element-type
type). On 64bit machines, in 2.7.0 the element types take 4 and 8 bytes
respectively, while in 2.6.14 both take 8. You should be able to read
and write these arrays without error in both cases. You won't be able
to retrieve the element type you used to make the array with
(array-element-type array), but rather just the upgraded type. This is
always the case in any lisp.
>
> The second problem is that apparently GCL does not flush file
> buffers on 'CLOSE'. Do I need to call 'FINISH-OUTPUT' before
> 'CLOSE'?
Do you have an example I can look into?
>
> The third problem is that apparently GCL writes wrong thing
> which it can not read back. The Lisp expression is somewhat
> complex, one can reproduce this from recent FriCAS using:
>
> kf := open("ts_kaf", "output")$KeyedAccessFile(None)
> a3 : EXPR(INT) := exp(x) - 1
> kf("a3") := a3 pretend None
>
> After that file 'ts_kaf/index.KAF' contains apparently wrong
> S-expression. Reading it back via:
>
I can confirm this, and that it is absent in 2.7.0. I will investigate
a patch and get back to you.
Take care,
> kr3 := kf("a3") pretend EXPR(INT)
>
> gives:
>
> >> System error:
> SIMPLE-ERROR: #2= multiply defined
>
> and '#2' indeed seem to be multiply defined.
>
> I wrote "recent" FriCAS because there were changes on FriCAS
> side which fixed some probles (and potentially may introduce
> new bugs). However this problem is also present in GCL
> compiled FriCAS 1.3.11.
>
> --
> Waldek Hebisch
--
Camm Maguire [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
--
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/87v7uds4y4.fsf%40maguirefamily.org.
