clean-graph-copy issueshttps://gitlab.science.ru.nl/clean-and-itasks/clean-graph-copy/-/issues2019-06-03T15:31:43+02:00https://gitlab.science.ru.nl/clean-and-itasks/clean-graph-copy/-/issues/5Mac 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.https://gitlab.science.ru.nl/clean-and-itasks/clean-graph-copy/-/issues/4Unboxed arrays cannot be serialized with names on Mac2018-11-05T11:20:02+01:00Camil StapsUnboxed arrays cannot be serialized with names on MacThe below program crashes with a segmentation fault on Mac. It works without problems on 64-bit linux.
```clean
module test
import StdEnv
import graph_copy_with_names
Start w = copy_to_string_with_names arr
where
arr :: {#Int}...The below program crashes with a segmentation fault on Mac. It works without problems on 64-bit linux.
```clean
module test
import StdEnv
import graph_copy_with_names
Start w = copy_to_string_with_names arr
where
arr :: {#Int}
arr = {#}
```https://gitlab.science.ru.nl/clean-and-itasks/clean-graph-copy/-/issues/3Examples missing2019-06-03T15:31:49+02:00Camil StapsExamples missingIt would be good to have examples of the various (de)serialization functions that can also serve as test cases.It would be good to have examples of the various (de)serialization functions that can also serve as test cases.https://gitlab.science.ru.nl/clean-and-itasks/clean-graph-copy/-/issues/2Is this repository up to date with the one in SVN?2019-06-03T15:31:14+02:00Camil StapsIs this repository up to date with the one in SVN?There are two versions of GraphCopy:
- In https://svn.cs.ru.nl/repos/clean-libraries/trunk/graph_copy (log at https://svn.camilstaps.nl/log.php?repname=clean-libraries&path=%2Ftrunk%2FLibraries%2Fgraph_copy%2F&isdir=1&)
- In https://git...There are two versions of GraphCopy:
- In https://svn.cs.ru.nl/repos/clean-libraries/trunk/graph_copy (log at https://svn.camilstaps.nl/log.php?repname=clean-libraries&path=%2Ftrunk%2FLibraries%2Fgraph_copy%2F&isdir=1&)
- In https://gitlab.science.ru.nl/clean-and-itasks/clean-graph-copy (log at https://gitlab.science.ru.nl/clean-and-itasks/clean-graph-copy/commits/master; this was previously in the iTasks repository with log at https://gitlab.science.ru.nl/clean-and-itasks/iTasks-SDK/commits/71b3c92ca46ab50ed4131edddbd9318be34e79fb/Dependencies/graph_copy)
It is unclear if the SVN version contains changes that are not in the git version (Jurriƫn at least merged some changes on 2016-05-30 judging from the iTasks log).https://gitlab.science.ru.nl/clean-and-itasks/clean-graph-copy/-/issues/1size_element_descriptor_currying should be 16 on more than just Mac2018-10-31T14:58:40+01:00Camil Stapssize_element_descriptor_currying should be 16 on more than just MacThis number indicates the number of bytes every element in the curry table takes up. In the [current version](https://gitlab.science.ru.nl/clean-and-itasks/clean-graph-copy/blob/f6abbff0e65e4990cd91b06abda6ab376ed37582/common/copy_graph_...This number indicates the number of bytes every element in the curry table takes up. In the [current version](https://gitlab.science.ru.nl/clean-and-itasks/clean-graph-copy/blob/f6abbff0e65e4990cd91b06abda6ab376ed37582/common/copy_graph_to_string.c#L38) it is 16 for Mac and 8 for everything else.
On 64-bit linux it should also be 16, and probably also on 64-bit windows. It is not clear to me why the Clean function cannot be just `IF_INT_64_OR_32 16 8`.