stepharo wrote
> storeOn: is old because it will not handle cycles and other.
> So I would simply use Ston.
I agree. I ran into two problems right away - internal references are not
maintained and it's easy to hit the literal array limit. However, my use
case is saving data in Pharo and loading it
storeOn: is old because it will not handle cycles and other.
So I would simply use Ston.
Stef
Le 14/6/15 06:20, Sean P. DeNigris a écrit :
Thierry Goubier wrote
There is some code in SmaCC to handle that.
Would it make sense to extract?
-
Cheers,
Sean
--
View this message in context:
Le 14/06/2015 06:20, Sean P. DeNigris a écrit :
Thierry Goubier wrote
There is some code in SmaCC to handle that.
Would it make sense to extract?
I'd try if it works for you first :)
Code is there:
https://github.com/ThierryGoubier/SmaCC/blob/d5371fbf3298fcf8a0053d5c122db76b08b0b7ca/SmaCC-
Thierry Goubier wrote
> There is some code in SmaCC to handle that.
Would it make sense to extract?
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/storeOn-and-literal-limits-tp4832255p4832324.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com
Le 13/06/2015 16:06, Sean P. DeNigris a écrit :
Does anything exist to handle uses of #storeOn: that bump into the literal
limit? E.g. that splits the offending constructor method into several
methods? Thanks.
There is some code in SmaCC to handle that.
Thierry
Does anything exist to handle uses of #storeOn: that bump into the literal
limit? E.g. that splits the offending constructor method into several
methods? Thanks.
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/storeOn-and-literal-limits-tp4832255.html
Sent from the Pha
