> > my work environment is using RedHat6/CentOS6 with glibc 2.12 >
That's seven years of unpatched security vulnerabilities! Are you sure you really want to stay at such great risk? On Tue, Aug 29, 2017 at 8:30 AM, Andreas Sunardi <a.suna...@gmail.com> wrote: > 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 >>> >> >> >
