March 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Ever growing image

by Marcus Denker

Maybe this: https://rmod.inria.fr/web/publications/bib?query=Poli17c&display=abstract Guillermo Polito, Luc Fabresse, Noury Bouraqadi, and StÃ©phane Ducasse. Run-Fail-Grow: Creating Tailored Object-Oriented Runtimes Producing a small deployment version of an application is a challenge because static abstractions such as packages cannot anticipate the use of their parts at runtime. Thus, an application often occupies more memory than actually needed. Tailoring is one of the main solutions to this problem i.e., extracting used code units such as classes and methods of an application. However, existing tailoring techniques are mostly based on static type annotations. These techniques cannot efficiently tailor applications in all their extent (e.g., runtime object graphs and metadata) nor be used in the context of dynamically-typed languages. We propose a run-fail-grow technique to tailor applications using their runtime execution. Run-fail-grow launches (a) a reference application containing the original application to tailor and (b) a nurtured application containing only a seed with a minimal set of code units the user wants to ensure in the final application. The nurtured application is executed, failing when it founds missing objects, classes or methods. On failure, the necessary elements are installed into the nurtured application from the reference one, and the execution resumes. The nurtured application is executed until it finishes, or until the developer explicitly finishes it, for example in the case of a web application. resulting in an object memory (i.e., a heap) with only objects, classes and methods required to execute the application. To validate our approach we implemented a tool based on Virtual Machine modifications, namely Tornado. Tornado succeeds to create very small memory footprint versions of applications e.g., a simple object-oriented heap of 11kb. We show how tailoring works on application code, base and third-party libraries even supporting human interaction with user G. interfaces. These experiments show memory savings ranging from 95\% to 99\%. > > yes, Mariano Peck made a PhD on that (when we were exploring âhow to get smaller imagesâ possibilities). > We finally went for bootstrap, but we made an analysis on all possibilities around. > Mariano was doing swapping outâ¦ Mariano Martinez Peck, Noury Bouraqadi, Marcus Denker, StÃ©phane Ducasse, and Luc Fabresse. Marea: An Efficient Application-Level Object Graph Swapper. Abstract Abstract During the execution of object-oriented applications, several millions of objects are created, used and then collected if they are not referenced. Problems appear when objects are unused but cannot be garbage-collected because they are still referenced from other objects. This is an issue because those objects waste primary memory and applications use more primary memory than they actually need. We claim that relying on the operating system's (OS) virtual memory is not always enough since it cannot take into account the domain and structure of applications. At the same time, applications have no easy way to parametrize nor cooperate with memory management. In this paper, we present Marea, an efficient application-level object graph swapper for object-oriented programming languages. Its main goal is to offer the programmer a novel solution to handle application-level memory. Developers can instruct our system to release primary memory by swapping out unused yet referenced objects to secondary memory. Our approach has been qualitatively and quantitatively validated. Our experiments and benchmarks on real-world applications show that Marea can reduce the memory footprint between 23\% and 36\%.

March 6, 2018

Re: [Pharo-users] Pharo for MacOs 10.6.8?

by Esteban Lorenzano

hi, I would say get.pharo.org/30+vm <http://get.pharo.org/30+vm> or get.pharo.org/20+vm <http://get.pharo.org/30+vm> one of both should work. there is also a chance that get.pharo.org/40+vm <http://get.pharo.org/30+vm> â¦ will work, but you need to try it ;) Esteban ps: but as Marcus say, it will be an older image and an older VM. Still very usable (as it *was* usable at the time), but not the fresh stuff :) > On 6 Mar 2018, at 08:47, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 5 Mar 2018, at 20:16, stefano franchi <stefano.franchi(a)gmail.com <mailto:stefano.franchi@gmail.com>> wrote: >> >> >> >> On Mon, Mar 5, 2018 at 11:28 AM, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: >> Did you check >> >> http://get.pharo.org <http://get.pharo.org/> >> >> because we keep everything. >> >> >> >> Apologies for not having stated my question more precisely. Indeed, I started from get.pharo.org <http://get.pharo.org/>, but the zeroconf script did not guess right. The app it downloaded crashes at startup. Then I saw the *long* list of versions available and had no idea where to begin. So my real question is: >> >> Does anyone know which among the many VMs available on http://get.pharo.org <http://get.pharo.org/> would work on a MacOs Powerbook Pro running 10.6.9? It was the latest 32 bit only machine Apple made, based on the Intel Core Duo (NOT the Intel Core 2 Duo that came out a few months later). >> > you could look for old VMs and downloads here: http://files.pharo.org/ <http://files.pharo.org/> > > But it is quite hard to for us (with our limited man power) to support old machines foreverâ¦ e.g the vm from that time should run, > but at some point the VM gets improved and newer images require a newer VM as we want to actually use the features that > new VMs provide. > > Keeping everything compatible in all possible directions (old images on new VMs, new image on old VMs â¦) puts quite some > constraints on what you can do in futureâ¦ an maintaining new VMs for all possible old MacOS versions could soon just > use up all our manpower. > > So this is not a simple problem to solve. Even very financially capable projects (like Mozilla) can not support old MacOS > versions. And they spend 150K per *month* just on CI infrastructureâ¦ imagine if they decide to not support anything older > then MaOS 10.9â¦ can we? should we? > > There are things to do on this front, but if I would spend effort the first thing I would work on is running *old* images on > *new* VMs and explore what kind of abstraction would be needed to to that nicely and in a way that it can be maintained > and in a way that all the needed code ( e.g. translation byte code from old to new) would be not part of the VM but > part of the image. > > Making sure to run *current* images on old Machines can only be done by backporting the current VM to the old OS. > This should be not that hard, worst case is that you need to combine some old OS related code with the rest of the new VM, > but that should not be much. > > But one question: Considering what developer time costsâ¦ I am quite sure that it is cheaper to just buy a current Mac. > > Marcus >

March 6, 2018

Re: [Pharo-users] Ever growing image

by Esteban Lorenzano

yes, Mariano Peck made a PhD on that (when we were exploring âhow to get smaller imagesâ possibilities). We finally went for bootstrap, but we made an analysis on all possibilities around. Maybe he can point to itâ¦ Esteban > On 6 Mar 2018, at 04:35, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Marcus Denker-4 wrote >> (I had expected a bit more). > > I think I definitely read somewhere that there was a system that could > analyze the messages that were actually sent and remove everything else... > fun to think about the possibilities! > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

March 6, 2018

Re: [Pharo-users] Pharo for MacOs 10.6.8?

by Marcus Denker

> On 5 Mar 2018, at 20:16, stefano franchi <stefano.franchi(a)gmail.com> wrote: > > > > On Mon, Mar 5, 2018 at 11:28 AM, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > Did you check > > http://get.pharo.org <http://get.pharo.org/> > > because we keep everything. > > > > Apologies for not having stated my question more precisely. Indeed, I started from get.pharo.org <http://get.pharo.org/>, but the zeroconf script did not guess right. The app it downloaded crashes at startup. Then I saw the *long* list of versions available and had no idea where to begin. So my real question is: > > Does anyone know which among the many VMs available on http://get.pharo.org <http://get.pharo.org/> would work on a MacOs Powerbook Pro running 10.6.9? It was the latest 32 bit only machine Apple made, based on the Intel Core Duo (NOT the Intel Core 2 Duo that came out a few months later). > you could look for old VMs and downloads here: http://files.pharo.org/ But it is quite hard to for us (with our limited man power) to support old machines foreverâ¦ e.g the vm from that time should run, but at some point the VM gets improved and newer images require a newer VM as we want to actually use the features that new VMs provide. Keeping everything compatible in all possible directions (old images on new VMs, new image on old VMs â¦) puts quite some constraints on what you can do in futureâ¦ an maintaining new VMs for all possible old MacOS versions could soon just use up all our manpower. So this is not a simple problem to solve. Even very financially capable projects (like Mozilla) can not support old MacOS versions. And they spend 150K per *month* just on CI infrastructureâ¦ imagine if they decide to not support anything older then MaOS 10.9â¦ can we? should we? There are things to do on this front, but if I would spend effort the first thing I would work on is running *old* images on *new* VMs and explore what kind of abstraction would be needed to to that nicely and in a way that it can be maintained and in a way that all the needed code ( e.g. translation byte code from old to new) would be not part of the VM but part of the image. Making sure to run *current* images on old Machines can only be done by backporting the current VM to the old OS. This should be not that hard, worst case is that you need to combine some old OS related code with the rest of the new VM, but that should not be much. But one question: Considering what developer time costsâ¦ I am quite sure that it is cheaper to just buy a current Mac. Marcus

March 6, 2018

Re: [Pharo-users] PetitParser Question

by Julien

Hello, I think this blogpost is a good place to start: https://www.lukas-renggli.ch/blog/petitparser-1 <https://www.lukas-renggli.ch/blog/petitparser-1> There is also the chapter about PetitParser in Deep Into Pharo: http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/PetitParser.… <http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/PetitParser.…> Cheers, Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > Le 5 mars 2018 Ã 19:26, Asbath via Pharo-users <pharo-users(a)lists.pharo.org> a Ã©crit : > > > De: Asbath <asamabiyalou(a)yahoo.com> > Objet: PetitParser Question > Date: 5 mars 2018 Ã 19:26:49 UTC+1 > Ã: pharo-users(a)lists.pharo.org > > > Hi everybody, > > We are a group of students working on Pillar, and we notice that the Parser of Pillar is based on PetitParser Library. Then we want to know more about PetitParser !? > > Thanks, > > Asbath > > > >

March 6, 2018

Re: [Pharo-users] Ever growing image

by Sean P. DeNigris

Marcus Denker-4 wrote > (I had expected a bit more). I think I definitely read somewhere that there was a system that could analyze the messages that were actually sent and remove everything else... fun to think about the possibilities! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 6, 2018

Re: [Pharo-users] Bitwise operations in ByteArray (slicing, etc.)

by Esteban A. Maringolo

Hi Richard, Certainly a BitStream is beyond what I initially thought. But it could be of some use to play with it, is it available somewhere with a friendly open source license? I might give it a try using it for my generator (tests are already passing). Your example is almost complete, but if I understand it you're adding the size of the checksum instead of the checksum itself. Nonetheless I think its readability is superior, and I guess that it is better perfomance and memorywise. Also it could be useful for Base58Encoder I'm expermenting with. Encoding is "simple" but requires the use of a really large integer, I'm stuck at the decoding part now. After that there is a Base32 encoder (to implement a Bech32 encoder as well). So I might use it in my road of experimentation with these matters. Unless I diverge from this and abandon it as it normally happens. :/ Regarding this part: > This reminds me of a lesson I learned many years > ago: STRINGS ARE WRONG. (Thank you, designers of > Burroughs Extended Algol!) When trees aren't the > answer, streams often are. Can you provide more context to this? I wouldn't mind if it is in a separate thread or a blog post of your own. Thanks in advance. Esteban A. Maringolo 2018-03-05 21:55 GMT-03:00 Richard O'Keefe <raoknz(a)gmail.com>: > I note that the specification in question does not > deal with arbitrary bit strings but with "entropies" > that are 128 to 256 bits long and a multiple of 32 bits. > 4 to 8 bits are copied from the front to the end. > (So selecting *this* bit field can be done by taking > the first byte of a ByteArray.) This makes the sequence > 132 to 264 bits. This is then chopped into 11 bit > subsequences. These are not arbitrary subsequences and > they are not taken in arbitrary order. They are a stream. > > My own Smalltalk library include BitInputStream and > BitOutputStream, wrapping byte streams. So we could > do something like > > ent := aByteArray size * 8. "BIP-39 ENT" > cs := ent // 32. "BIP-39 CS" > foo := ByteArray new: (ent + cs) // 8. > o := BitOutputStream on: foo writeStream. > i := BitInputStream on: aByteArray readStream. > 1 to: ent do: [:x | o nextPut: i next]. > i reset. > o nextUnsigned: cs put: (i nextUnsigned: cs). > i close. > o close. > i := BitInputStream on: foo readStream. > ans := (1 to: (ent + cs) // 11) collect: [:x | > WordList at: 1 + (i nextUnsigned: 11)]. > > Stare at this for a bit, and you realise that you don't > actually need the working byte array foo. > ByteArray > methods for: 'bitcoin' > mnemonic > |ent csn i t| > (ent between: 128 and: 256) > ifFalse: [self error: 'wrong size for BIP-39']. > cs := ent // 32. > n := (ent + cs) // 11. > i := BitInputStream on: (ReadStream on: self). > t := i nextUnsigned: cs. > i reset. > ^(1 to: n) collect: [:index | > WordList at: 1 + (index = n > ifTrue: [((i nextUnsigned: 11 - cs) bitShift: cs) bitOr: t] > ifFalse: [i nextUnsigned: 11])] > > My BitInputStream and BitOutputStream classes are, > um, not really mature. They aren't *completely* > naive, but they could be a lot better, and in > particular, BitInputStream>>nextUnsigned: and > BitOutputStream>>nextUnsigned:put: are definitely > suboptimal. I put this out there just to suggest > that there is a completely different way of thinking > about the problem. (Actually, this isn't *entirely* > unlike using Erlang bit syntax.) > > Bit*Streams are useful enough to justify primitive > support. (Which my classes don't have yet. I did > say they are not mature...) > > This reminds me of a lesson I learned many years > ago: STRINGS ARE WRONG. (Thank you, designers of > Burroughs Extended Algol!) When trees aren't the > answer, streams often are. > > > > > On 6 March 2018 at 07:21, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >> 2018-03-05 14:02 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> > On Sun, Mar 4, 2018 at 9:43 PM, Esteban A. Maringolo >> > <emaringolo(a)gmail.com> wrote: >> >> 2018-03-04 17:15 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >>> Bits are actually numbered from right to left (seen from how they are >> >>> printed). >> >> >> >> I understand bit operations, used it extensively with IP address eons >> >> ago. >> >> >> >> But if a spec says: "Take the first n bits from the hash", it means >> >> the first significant bits. >> >> so in 2r100101111 the first 3 bits are "100" and not "111". >> > >> > naive question: why? >> >> Because it says so. >> "A checksum is generated by taking the first ENT / 32 bits of its >> SHA256 hash. This checksum is appended to the end of the initial >> entropy. >> Next, these concatenated bits are split into groups of 11 bits, each >> encoding a number from 0-2047, serving as an index into a wordlist. >> Finally, we convert these numbers into words and use the joined words >> as a mnemonic sentence." [1]. >> >> > To me it looks like a lousy specification. >> >> It might be, I can't really tell. >> >> But such manipulation could be useful if you are knitting different >> parts of a binary packet whose boundaries are not at byte level, but >> bit instead. So you can take "these 5 bits, concatenate with this >> other 7, add 13 zero bits, then 1 followed by the payload". I'm >> assuming a non real case here though, my use case was fulfilled >> already. >> >> Regards! >> >> -- >> Esteban A. Maringolo >> >> [1] >> https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#generating-t… >> >

March 6, 2018

[ANN] 64 bits support preview

by Mariano Martinez Peck

Hi guys, Thanks for Guillermo Polito we now have 64 bits support for OSSubprocess. You can see the required changes in this PR [1]. I made a branch called `support64bits` so that you can help us test it even if CI said it was good [2]. If you do test it and come back to us with the results, please tell us which OS you used. To install from the branch: Metacello new configuration: 'OSSubprocess'; repository: 'github://marianopeck/OSSubprocess:support64bits/repository'; version: #stable; load. Roadmap: Current release is v0.2.5. So I will let that release for Pharo <= 5.0. I will make a new release with the Pharo 64 bits and call it v0.3. That release should be used for Pharo 6.x. Once v0.3 is out, I will make a new release v0.4 with some changes I wanted to do since a loooong time and its a small refactor to minimize OSSubprocess dependency on OSProcesses primitives (at VM side). This is thanks to Holger Freyther and Alistair Grant [3]. As that requires a new VM, then v0.4 should be used in Pharo >= 7.0. Cheers, [1] https://github.com/marianopeck/OSSubprocess/pull/30 [2] https://travis-ci.org/guillep/OSSubprocess/builds/349280174 [3] https://github.com/pharo-project/pharo-vm/pull/142 -- Mariano http://marianopeck.wordpress.com

March 6, 2018

Re: [Pharo-users] Bitwise operations in ByteArray (slicing, etc.)

by Richard O'Keefe

I note that the specification in question does not deal with arbitrary bit strings but with "entropies" that are 128 to 256 bits long and a multiple of 32 bits. 4 to 8 bits are copied from the front to the end. (So selecting *this* bit field can be done by taking the first byte of a ByteArray.) This makes the sequence 132 to 264 bits. This is then chopped into 11 bit subsequences. These are not arbitrary subsequences and they are not taken in arbitrary order. They are a stream. My own Smalltalk library include BitInputStream and BitOutputStream, wrapping byte streams. So we could do something like ent := aByteArray size * 8. "BIP-39 ENT" cs := ent // 32. "BIP-39 CS" foo := ByteArray new: (ent + cs) // 8. o := BitOutputStream on: foo writeStream. i := BitInputStream on: aByteArray readStream. 1 to: ent do: [:x | o nextPut: i next]. i reset. o nextUnsigned: cs put: (i nextUnsigned: cs). i close. o close. i := BitInputStream on: foo readStream. ans := (1 to: (ent + cs) // 11) collect: [:x | WordList at: 1 + (i nextUnsigned: 11)]. Stare at this for a bit, and you realise that you don't actually need the working byte array foo. ByteArray methods for: 'bitcoin' mnemonic |ent csn i t| (ent between: 128 and: 256) ifFalse: [self error: 'wrong size for BIP-39']. cs := ent // 32. n := (ent + cs) // 11. i := BitInputStream on: (ReadStream on: self). t := i nextUnsigned: cs. i reset. ^(1 to: n) collect: [:index | WordList at: 1 + (index = n ifTrue: [((i nextUnsigned: 11 - cs) bitShift: cs) bitOr: t] ifFalse: [i nextUnsigned: 11])] My BitInputStream and BitOutputStream classes are, um, not really mature. They aren't *completely* naive, but they could be a lot better, and in particular, BitInputStream>>nextUnsigned: and BitOutputStream>>nextUnsigned:put: are definitely suboptimal. I put this out there just to suggest that there is a completely different way of thinking about the problem. (Actually, this isn't *entirely* unlike using Erlang bit syntax.) Bit*Streams are useful enough to justify primitive support. (Which my classes don't have yet. I did say they are not mature...) This reminds me of a lesson I learned many years ago: STRINGS ARE WRONG. (Thank you, designers of Burroughs Extended Algol!) When trees aren't the answer, streams often are. On 6 March 2018 at 07:21, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2018-03-05 14:02 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > > On Sun, Mar 4, 2018 at 9:43 PM, Esteban A. Maringolo > > <emaringolo(a)gmail.com> wrote: > >> 2018-03-04 17:15 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >>> Bits are actually numbered from right to left (seen from how they are > printed). > >> > >> I understand bit operations, used it extensively with IP address eons > ago. > >> > >> But if a spec says: "Take the first n bits from the hash", it means > >> the first significant bits. > >> so in 2r100101111 the first 3 bits are "100" and not "111". > > > > naive question: why? > > Because it says so. > "A checksum is generated by taking the first ENT / 32 bits of its > SHA256 hash. This checksum is appended to the end of the initial > entropy. > Next, these concatenated bits are split into groups of 11 bits, each > encoding a number from 0-2047, serving as an index into a wordlist. > Finally, we convert these numbers into words and use the joined words > as a mnemonic sentence." [1]. > > > To me it looks like a lousy specification. > > It might be, I can't really tell. > > But such manipulation could be useful if you are knitting different > parts of a binary packet whose boundaries are not at byte level, but > bit instead. So you can take "these 5 bits, concatenate with this > other 7, add 13 zero bits, then 1 followed by the payload". I'm > assuming a non real case here though, my use case was fulfilled > already. > > Regards! > > -- > Esteban A. Maringolo > > [1] https://github.com/bitcoin/bips/blob/master/bip-0039. > mediawiki#generating-the-mnemonic > >

March 6, 2018

Re: [Pharo-users] my mistake on Spec?

by Stephane Ducasse

You should initialize the instance variable #subjectTextInput I suggest to do your UI incrementally. Stef On Mon, Mar 5, 2018 at 9:08 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > defaultSpec2 > <spec: #default> > ^ SpecLayout composed > newColumn: [ :col | > col > newRow: [ :row | > row > add: #plaintiffsTextInput; > add: #addButtonPlaintiffs ]; > newRow: [ :row | > row > add: #defendantsTextInput; > add: #addButtonDefendants ]; > newRow: [ :row | > row > add: #thirdPartiesTextInput; > add: #addButtonThirdParties ]; > newRow: [ :row | row add: #addButtonCourtCase ] ]; > yourself > > is working > > > > > > > On Mon, Mar 5, 2018 at 9:00 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> I'm trying to understand. >> I do not get a DNU with the following. You cannot put row out of nowhere. >> >> defaultSpec >> ^ SpecLayout composed >> newColumn: [ :col | >> col >> newRow: [ :row | >> row >> add: #plaintiffsTextInput; >> add: #addButtonPlaintiffs ]; >> newRow: [ :row | >> row >> add: #defendantsTextInput; >> add: #addButtonDefendants ]; >> newRow: [ :row | >> row >> add: #thirdPartiesTextInput; >> add: #addButtonThirdParties ] ]; >> yourself >> >> Now I do not understand why when I add the next lines I get an error >> >> >> >> >> >> >> >> >> On Mon, Mar 5, 2018 at 7:03 PM, Yuriy Babah <babah.yuriy06(a)gmail.com> wrote: >>> yesterday i did it, and got --> doesNotUndestand #layout >>> >>> 2018-03-05 20:28 GMT+03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>> >>>> First implement all the missing methods that you use in the spec class >>>> method. >>>> Then let us know. >>>> >>>> Stef >>>> >>>> >>>> On Sun, Mar 4, 2018 at 2:56 PM, Yuriy Babah <babah.yuriy06(a)gmail.com> >>>> wrote: >>>> > Thanks for your help, Stef. >>>> > Mistakes remain, but I will try to understand them >>>> > >>>> > 2018-03-04 16:35 GMT+03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>> >> >>>> >> I'm doing a pass on your code >>>> >> >>>> >> OrderedCollection new is better to me than #() asOrderedCollection. >>>> >> >>>> >> GUI_ListCourtCase new openWithSpec >>>> >> => DNU >>>> >> So I added the first missing method, but you should define the >>>> >> corresponding methods in the class. >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> On Sun, Mar 4, 2018 at 2:28 PM, Stephane Ducasse >>>> >> <stepharo.self(a)gmail.com> wrote: >>>> >> > Hi yuri >>>> >> > >>>> >> > some feedback before looking into spec. >>>> >> > tab method bodies >>>> >> > then do not use instance variables with uppercase. >>>> >> > >>>> >> > Stef >>>> >> > >>>> >> > >>>> >> > On Sun, Mar 4, 2018 at 2:26 PM, Yuriy Babah <babah.yuriy06(a)gmail.com> >>>> >> > wrote: >>>> >> >> changed >>>> >> >> >>>> >> >> 2018-03-04 16:20 GMT+03:00 Yuriy Babah <babah.yuriy06(a)gmail.com>: >>>> >> >>> >>>> >> >>> Is it enough if I just attach it? >>>> >> >>> >>>> >> >>> I slightly changed the code, that leads to error: "DoesNotUndestand >>>> >> >>> #plaintiffsTextInput" . >>>> >> >>> >>>> >> >>> Now I'm studying Help on Spec in SystemBrowser . >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> 2018-03-04 15:23 GMT+03:00 Stephane Ducasse >>>> >> >>> <stepharo.self(a)gmail.com>: >>>> >> >>>> >>>> >> >>>> Hi Yuriy >>>> >> >>>> >>>> >> >>>> this is difficult to debug remotely. Do you have your code >>>> >> >>>> somewhere? >>>> >> >>>> >>>> >> >>>> Stef >>>> >> >>>> >>>> >> >>>> On Sat, Mar 3, 2018 at 8:41 AM, Yuriy Babah >>>> >> >>>> <babah.yuriy06(a)gmail.com> >>>> >> >>>> wrote: >>>> >> >>>> > Hi! >>>> >> >>>> > I'm trying to write GUI element with Spec, Pharo6.1x64 on Linux. >>>> >> >>>> > Do according to the SpecBooklet. >>>> >> >>>> > >>>> >> >>>> > Finished the fragment, and try do: >>>> >> >>>> > >>>> >> >>>> > ui := GUI_ListCourtCase new openWithSpec . -> #value was sent to >>>> >> >>>> > nil. >>>> >> >>>> > >>>> >> >>>> > I look in a debugger and: >>>> >> >>>> > >>>> >> >>>> > openWithSpecLayout: aSpec >>>> >> >>>> > "Build the widget using the spec name provided as argument >>>> >> >>>> > and >>>> >> >>>> > display >>>> >> >>>> > it into a window" >>>> >> >>>> > >>>> >> >>>> > (window value notNil and: [ self needRebuild not ]) >>>> >> >>>> > ifTrue: [ "window != nil" >>>> >> >>>> > window value rebuildWithSpecLayout: aSpec ] >>>> >> >>>> > ifFalse: [ "If value = Nil --> send him a message >>>> >> >>>> > ???" >>>> >> >>>> > window value: (self defaultWindowModelClass new >>>> >> >>>> > model: >>>> >> >>>> > self). >>>> >> >>>> > window value openWithSpecLayout: aSpec. >>>> >> >>>> > self takeKeyboardFocus ]. >>>> >> >>>> > >>>> >> >>>> > ^ window value >>>> >> >>>> >>>> >> >>> >>>> >> >> >>>> > >>>> > >>>> >>>

March 5, 2018