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
