That sounds good. Unfortunately for me, my work environment is using RedHat6/CentOS6 with glibc 2.12. Is there Pharo6 with glibc < 2.15 support. Or is there a way for me to build that myself?
It's quite a departure to change my DSL into defining multiple methods. But that's my own problem. I'm happy to hear Pharo 6 can support a lot more literals. I tested my code on Pharo 6 (on my Windows box) and it works. I see SistaV1 compiler in Pharo 5 setting, but that causes Pharo to crash. Thank you guys for your answers. I think I have the information I need to make decision. But if there is a way to get Pharo 6 that works with glibc < 2.15, please let me know. Thank you -- Andreas On Tue, Aug 29, 2017 at 12:34 AM, Clément Bera <bera.clem...@gmail.com> wrote: > Hi, > > If your tool works in Pharo 6, you can use the other bytecode set which > supports up to 32k literals. To do so, go to: > World Menu > Settings > Compiler > Encoder > and pick SistaV1 instead of V3PlusClosures > Try to load your code. The default Pharo 6 VM supports both bytecode sets. > > Alternatively you need to split your methods with many literals in > multiple methods with less literals, which is usually quite tricky to do > right. > > On Tue, Aug 29, 2017 at 4:52 AM, Andreas Sunardi <a.suna...@gmail.com> > wrote: > >> I have written a tool (Pharo5) where user gives an input file to it, >> where the content is a smalltalk code, a DSL. I used a subclass of >> CodeImporter class to evaluate this input file. >> >> Recently my user used an input file where it hit the 256 literal limit >> (total of unique string, number, method name, etc), down in >> OpalEncoderForV3PlusClosures >> genPushLiteral:. The number seems to be >> hard coded and related to byte code generator, not something I can simply >> increase. I wasn't aware of this limitation. >> >> Before I overhaul my tool, I thought I should ask. Is there another >> alternative to evaluate a smalltalk file/script? The file is small, 27k, >> but the number of unique literals in it is > 256. Is it possible at all, >> seeing that the limit is related to byte code generator. >> >> Thank you in advance >> -- >> Andreas Sunardi >> > >
