[Pharo-project] Limitation of number os literals in a method?

I get that error when I try save a CLView builded with the UIBuilder More than 256 literals referenced. You must split or otherwise simplify this method. The 257th literal is: 128 Select Proceed to continue, or close this window to cancel the operation. How I can solve that problem? The meth

Re: [Pharo-project] Limitation of number os literals in a method?

On Sat, Jul 31, 2010 at 1:57 AM, nullPointer wrote: > > I get that error when I try save a CLView builded with the UIBuilder > > More than 256 literals referenced. > You must split or otherwise simplify this method. > The 257th literal is: 128 > > Select Proceed to continue, or close this window

Re: [Pharo-project] Limitation of number os literals in a method?

That is the method with the problems: http://paste.lisp.org/display/113020 -- View this message in context: http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp2308740p2308973.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _

Re: [Pharo-project] Limitation of number os literals in a method?

> "nullPointer" == nullPointer writes: nullPointer> That is the method with the problems: nullPointer> http://paste.lisp.org/display/113020 Eww. I hope that method was generated automatically, and that humans can maintain something that *generates* that method. Otherwise, it's a

Re: [Pharo-project] Limitation of number os literals in a method?

XD -- View this message in context: http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp2308740p2308991.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.i

Re: [Pharo-project] Limitation of number os literals in a method?

eliot in VW did windows spec faced such a limit and relied on such bytecodes? I imagine that this is the case but... Stef On Jul 31, 2010, at 6:10 PM, Eliot Miranda wrote: > > On Sat, Jul 31, 2010 at 1:57 AM, nullPointer wrote: > > I get that error when I try save a CLView builded with the U

Re: [Pharo-project] Limitation of number os literals in a method?

did you try to generate a string (I know this is not the same) container := CLPanel new. container name: 'container'. container text: ''. container usePolymorphStyleMechanism: true. container balloonText: nil. container enabled: true. container locat

Re: [Pharo-project] Limitation of number os literals in a method?

I´m looking for use of strings. That could be a solution... "container" container := CLPanel new. Compiler new evaluate: 'container name: ''container''. container text: . container usePolymorphStyleMechanism: true. container balloonText: nil.

Re: [Pharo-project] Limitation of number os literals in a method?

Finnally I call for each widget another method spec for configure it. Is possible now reproduce the same error, but is much more difficult. http://paste.lisp.org/display/113020#1 I wait that version it seems less revolting to Randal xD I will upload that fix in SqueakSource UIBuilder project.

Re: [Pharo-project] Limitation of number os literals in a method?

a suggestion lblImage does not read well in Smalltalk labelImage is way better and you only need two extra characters. Favor readibility. Stef On Aug 2, 2010, at 2:53 PM, nullPointer wrote: > > Finnally I call for each widget another method spec for configure it. Is > possible now reproduce

Re: [Pharo-project] Limitation of number os literals in a method?

If performance is not a problem , then you could wrap things in one array, like: array := #( ( #selector1 arg1 arg2 arg3) ( #selector2 arg1 arg2 arg3) ( #selector3 arg1 arg2 arg3) ( #selector4 arg1 arg2 arg3) ... ) then in compiled method you'll have only a single literal - and outer array, and

Re: [Pharo-project] Limitation of number os literals in a method?

ok so now this is exactly the VW windowspec and I understand why they did it like that. They have a declarative expression with multiple possible interpretations I was not sure that literal inside arrays where in the literal frame but I was stupid. Stef > If performance is not a problem , then