clean-libraries issueshttps://gitlab.science.ru.nl/clean-and-itasks/clean-libraries/-/issues2020-09-05T14:09:19+02:00https://gitlab.science.ru.nl/clean-and-itasks/clean-libraries/-/issues/6Non-blocking TCP library2020-09-05T14:09:19+02:00Camil StapsNon-blocking TCP libraryThere is an old non-blocking TCP library (described in §14.4 of the [ObjectIO tutorial](http://clean.cs.ru.nl/download/supported/ObjectIO.1.2/doc/tutorial.pdf)). There are currently two versions of this code:
1. In Libraries/TCPIP/Objec...There is an old non-blocking TCP library (described in §14.4 of the [ObjectIO tutorial](http://clean.cs.ru.nl/download/supported/ObjectIO.1.2/doc/tutorial.pdf)). There are currently two versions of this code:
1. In Libraries/TCPIP/ObjectIO
2. In ObjectIO/Tcp
The second *also* includes code from the standard TCP library. The second is currently broken (see !11).
Neither of these libraries are currently included in any distribution and I haven't been able to find any example using them either.
It seems to me like the most reasonable is to move the code in Libraries/TCPIP/ObjectIO to ObjectIO/ObjectIO, and to remove ObjectIO/Tcp. That way TCPIP only contains the cross-platform standard (blocking) TCP library, and the non-blocking interface which can only be used in ObjectIO is included in the lib-objectio nightly build. Does that sound good to you @peter88 (I think you know best what to do here)?https://gitlab.science.ru.nl/clean-and-itasks/clean-libraries/-/issues/4GraphCopy compatibility between 32-bit and 64-bit executables2020-04-26T13:55:44+02:00Camil StapsGraphCopy compatibility between 32-bit and 64-bit executablesCurrently GraphCopy represents values as 8 bytes on 64-bit systems and as 4 bytes on 32-bit systems, so it is not possible to copy a string representation of a graph from one platform to the other (and the "with names" variant is irrelev...Currently GraphCopy represents values as 8 bytes on 64-bit systems and as 4 bytes on 32-bit systems, so it is not possible to copy a string representation of a graph from one platform to the other (and the "with names" variant is irrelevant for this, of course). It would be useful to have this for the "with names" variant.
The ABC interpreter also relies on GraphCopy to (de)serialize values, so while the interpreter now works on 32-bit and 64-bit platforms and can run 32-bit and 64-bit ABC code, it is not possible yet on a 64-bit platform to deserialize a value serialized on a 32-bit platform, or vice versa. This also impacts iTasks, which currently works on 64-bit platforms because we can share a 64-bit graph representation with WebAssembly, which is also 64-bit.
To get this fixed I see two options:
1. Functions to convert a 32-bit graph-as-a-string to a 64-bit graph-as-a-string (and vice versa). The main difficulty here is that Real constants should be 64-bit on both platforms. For `REAL` nodes that's easy; for records with unboxed Reals it is possible (through the type string) but more difficult.
2. An option to let GraphCopy on 32-bit systems give a 64-bit string as output. The main difficulty here is that this option needs to be passed everywhere, e.g. in functions like `replace_desc_numbers_by_descs` which walk through the string: `IF_INT_64_OR_32 8 4` there would become `IF_INT_64_OR_32 8 (if compat64 8 4)` or something like that. It seems this would be more work but less error-prone.
I don't have a clear preference yet. Do you see other options, @johnvg?https://gitlab.science.ru.nl/clean-and-itasks/clean-libraries/-/issues/2Mac symbols_in_program gives unexpected values2019-06-03T15:31:43+02:00Camil StapsMac symbols_in_program gives unexpected valuesI would expect this program to show the symbol values of `__Cons` and `__Nil` followed by the same values as collected by `read_symbols`:
```clean
module test
import StdEnv
import symbols_in_program
Start w
# (syms,w) = accFiles (read...I would expect this program to show the symbol values of `__Cons` and `__Nil` followed by the same values as collected by `read_symbols`:
```clean
module test
import StdEnv
import symbols_in_program
Start w
# (syms,w) = accFiles (read_symbols "./a.out") w
= (descriptor [1,2,3], descriptor [], {#s \\ s <-: syms | isMember s.symbol_name ["__Cons","__Nil"]})
descriptor :: !a -> Int
descriptor _ = code {
get_node_arity 0
pushI 8
mulI
pushI 2
addI
pushD_a 0
subI
pop_a 1
}
```
This works on 64-bit linux:
> `(6596068,6596040,{Symbol "__Cons" 6596068,Symbol "__Nil" 6596040})`
But not on Mac:
> `(4444321560,4444321608,{Symbol "__Cons" 4295288632,Symbol "__Nil" 4295288600})`
The problem can be overcome by checking the difference between the symbol found for `__ARRAY__` and the actual address of `__ARRAY__` and adding that offset to each value. But it seems that should be done in `symbols_in_program` rather than elsewhere; the numbers returned by `read_symbols` now are meaningless.