November 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] How to add a morph to a Spec GUI

by Nicolai Hess

2014-11-16 10:02 GMT+01:00 kilon alios <kilon.alios(a)gmail.com>: > Hello guys I am trying to add a morph to spec gui before a spec button and > the experience has been a nightmare so far. > > > https://github.com/kilon/Nireas/blob/master/Nireas.package/Nireas.class/cla… > What do you mean "add a morph to spec gui". The common way is to define your own model and instead of composing your GUI with different morphs, you compose your GUI with different (ready-made) models. If you need a new kind of 1 model-GUI-Widget you'll have to define your own spec (morphic)adapter and add a spec binding. If you just want to add an existing morph into your layout, you can use Morphic>>#asSpecAdapter. This example looks a bit ugly, just because it uses a DynamicComposableModel. In your own applicatoin you would define your own model for defining and composing the parts: class:=AthensFlakeDemo. method:=AthensFlakeDemo>>#initialize. composed:= DynamicComposableModel new. composed instantiateModels: #(code TextModel method TextInputFieldModel). "this is a hack, as #instantiateModels: does not work for non-spec-models" composed widgets at:#demo put:(AthensFlakeDemo new asSpecAdapter). "with your own model (instead of using DynamicComposableModel) you would" "define a method that returns the morph asSpecadapter " composed code text:method sourceCode. composed method text: method selector asString. composed code aboutToStyle:true. composed code behavior:class. composed title:(class asString). composed openWithSpecLayout:( SpecLayout composed newColumn:[:r | r add: #demo height:80; add: #method height:25; add: #code]; yourself). > > I understand how columns and rows work but I cant figure out how Spec > works with Morphs. > > I took a look at CheckBoxExample but it completely jammed my brain how > complex it looks. > > First of all defaultSpec2 is what ? and whats the diffirence with > defaultSpec ? > > Dont know about you but I don't like neither name defaultSpec and > defaultSpec2 , I would have chosen a name like layout or something that > makes sense. > > also why we need to initializeWidgets when we already define their order > in defaultSpec ? Why cant Spec initialise those widgets by itself ? > > Is it really necessary for each element of the gui to be defined as a > getter method ? Why not just put everything to a dictionary and make a > getter for that dictionary ? It would make a complex Spec gui a nightmare > to browser and leads to braking it up to more classes which will still make > it a mess to browse. > > I see also a container defined in there , I assume it has something to do > with the morphs. > > I took also a look at documentation at Pharo for the Enterprise and it has > a section for building widgets but it looks too much work to add just a few > morph to a Spec gui. > > I wanted to make the gui for Nireas with Spec and I like some of its > design but overall it has been way more struggle than working with Morphic. > > I know I have complained about Spec before and sorry if I sound like a > broken tape but making guis in heavily gui based environment like Pharo > should not be so hard. > > I dont have a problem failing back to Morphic but since I see so many > people praise Spec I keep wondering if I approach this the wrong way and > things are much more elegant and easy than they look. >

Nov. 16, 2014

How to add a morph to a Spec GUI

by kilon alios

Hello guys I am trying to add a morph to spec gui before a spec button and the experience has been a nightmare so far. https://github.com/kilon/Nireas/blob/master/Nireas.package/Nireas.class/cla… I understand how columns and rows work but I cant figure out how Spec works with Morphs. I took a look at CheckBoxExample but it completely jammed my brain how complex it looks. First of all defaultSpec2 is what ? and whats the diffirence with defaultSpec ? Dont know about you but I don't like neither name defaultSpec and defaultSpec2 , I would have chosen a name like layout or something that makes sense. also why we need to initializeWidgets when we already define their order in defaultSpec ? Why cant Spec initialise those widgets by itself ? Is it really necessary for each element of the gui to be defined as a getter method ? Why not just put everything to a dictionary and make a getter for that dictionary ? It would make a complex Spec gui a nightmare to browser and leads to braking it up to more classes which will still make it a mess to browse. I see also a container defined in there , I assume it has something to do with the morphs. I took also a look at documentation at Pharo for the Enterprise and it has a section for building widgets but it looks too much work to add just a few morph to a Spec gui. I wanted to make the gui for Nireas with Spec and I like some of its design but overall it has been way more struggle than working with Morphic. I know I have complained about Spec before and sorry if I sound like a broken tape but making guis in heavily gui based environment like Pharo should not be so hard. I dont have a problem failing back to Morphic but since I see so many people praise Spec I keep wondering if I approach this the wrong way and things are much more elegant and easy than they look.

Nov. 16, 2014

Re: [Pharo-dev] New Cog VMs available

by Douglas McPherson

â¦ and ARMv6 and ARMv7 stack and stack/spur VMs updated accordingly. Doug > On Nov 15, 2014, at 19:24, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > > problems solved. So new VMs available at http://www.mirandabanda.org/files/Cog/VM/VM.r3137/ <http://www.mirandabanda.org/files/Cog/VM/VM.r3137/>. > > CogVM binaries as per VMMaker.oscog-eem.935/r3137 > > These VMs should be functionally identical to the 3126 VMs; the core VM differs > only in having been compiled from generated source that has been refactored to > enable convenient 32-bit to 64-bit Spur image bootstrap. I'm building and > releasing them mostly to test that refactoring. However, there is new DNS > support on Windows and SSL support on Unix. See below. > > Simulator/Slang: > Refactor to allow 32-bit and 64-bit Spur to coexist > in the simulator, thereby allowing a 64-bit bootstrap. > > Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and BaseHeaderSize > with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize respectively. > Make sure these are still output as the manifest constants in the generated C. > Eliminate use of bytesPerSlot in favour of bytesPerOop. The use of sends is > similar to those in trunk VMMaker, but I don't have time to merge. Sorry :-(. > > Work-around use of sends for bytesPerOop in e.g. generateToByDo:on:indent: and > users of isConstantNode:valueInto:. > > Do a better job at inlining via inlineCodeOrNilForStatement:in:. Comment in > isNode:substitutableFor:inMethod:in: explains. > > Eliminate generic VM_LABEL support, labelling only the bytecodes in interpret. > > Eliminate use of LargeContextSize in the stack and cog VMs. Alas haven't yet > eliminated the frame offset constants such as FoxCallerSavedIP et al. We only > need one of the two word sizes of interpreter to be executable in the bootstrap. > > And remember to generate the GdbARMPlugin > > Add accessorDepths for the exported browser plugin primitives for Spur. > > Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix. > See http://squeakvm.org/cgi-bin/viewvc.cgi/squeak?view=revision&revision=2249 <http://squeakvm.org/cgi-bin/viewvc.cgi/squeak?view=revision&revision=2249> > http://bugs.squeak.org/view.php?id=7824 <http://bugs.squeak.org/view.php?id=7824> > > Have the Unix & Mac VMs print the process id and working directory when blocking > on error or assert fail. Add scripts for the ARM VM archives. > > > On Fri, Nov 14, 2014 at 3:11 PM, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3133/ <http://www.mirandabanda.org/files/Cog/VM/VM.r3133/>. > > CogVM binaries as per VMMaker.oscog-eem.934/r3133 > These VMs should be functionally identical to the 3126 VMs; the core VM differs > only in having been compiled from generated source that has been refactored to > enable convenient 32-bit to 64-bit Spur image bootstrap. I'm building and > releasing them mostly to test that refactoring. However, there is new DNS > support on Windows and SSL support on Unix. See below. > > Simulator/Slang: > Refactor to allow 32-bit and 64-bit Spur to coexist > in the simulator, thereby allowing a 64-bit bootstrap. > > Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and BaseHeaderSize > with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize respectively. > Make sure these are still output as the manifest constants in the generated C. > Eliminate use of bytesPerSlot in favour of bytesPerOop. The use of sends is > similar to those in trunk VMMaker, but I don't have time to merge. Sorry :-(. > > Work-around use of sends for bytesPerOop in e.g. generateToByDo:on:indent: and > users of isConstantNode:valueInto:. > > Do a better job at inlining via inlineCodeOrNilForStatement:in:. Comment in > isNode:substitutableFor:inMethod:in: explains. > > Eliminate generic VM_LABEL support, labelling only the bytecodes in interpret. > > Eliminate use of LargeContextSize in the stack and cog VMs. Alas haven't yet > eliminated the frame offset constants such as FoxCallerSavedIP et al. We only > need one of the two word sizes of interpreter to be executable in the bootstrap. > > And remember to generate the GdbARMPlugin > > Add accessorDepths for the exported browser plugin primitives for Spur. > > Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix. > See http://squeakvm.org/cgi-bin/viewvc.cgi/squeak?view=revision&revision=2249 <http://squeakvm.org/cgi-bin/viewvc.cgi/squeak?view=revision&revision=2249> > http://bugs.squeak.org/view.php?id=7824 <http://bugs.squeak.org/view.php?id=7824> > > Have the Unix & Mac VMs print the process id and working directory when blocking > on error or assert fail. Add scripts for the ARM VM archives. > -- > best, > Eliot > > > > -- > best, > Eliot

Nov. 16, 2014

Re: [Pharo-dev] New Cog VMs available

by Eliot Miranda

Hi All, problems solved. So new VMs available at http://www.mirandabanda.org/files/Cog/VM/VM.r3137/. CogVM binaries as per VMMaker.oscog-eem.935/r3137 These VMs should be functionally identical to the 3126 VMs; the core VM differs only in having been compiled from generated source that has been refactored to enable convenient 32-bit to 64-bit Spur image bootstrap. I'm building and releasing them mostly to test that refactoring. However, there is new DNS support on Windows and SSL support on Unix. See below. Simulator/Slang: Refactor to allow 32-bit and 64-bit Spur to coexist in the simulator, thereby allowing a 64-bit bootstrap. Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and BaseHeaderSize with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize respectively. Make sure these are still output as the manifest constants in the generated C. Eliminate use of bytesPerSlot in favour of bytesPerOop. The use of sends is similar to those in trunk VMMaker, but I don't have time to merge. Sorry :-(. Work-around use of sends for bytesPerOop in e.g. generateToByDo:on:indent: and users of isConstantNode:valueInto:. Do a better job at inlining via inlineCodeOrNilForStatement:in:. Comment in isNode:substitutableFor:inMethod:in: explains. Eliminate generic VM_LABEL support, labelling only the bytecodes in interpret. Eliminate use of LargeContextSize in the stack and cog VMs. Alas haven't yet eliminated the frame offset constants such as FoxCallerSavedIP et al. We only need one of the two word sizes of interpreter to be executable in the bootstrap. And remember to generate the GdbARMPlugin Add accessorDepths for the exported browser plugin primitives for Spur. Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix. See http://squeakvm.org/cgi-bin/viewvc.cgi/squeak?view=revision&revision=2249 http://bugs.squeak.org/view.php?id=7824 Have the Unix & Mac VMs print the process id and working directory when blocking on error or assert fail. Add scripts for the ARM VM archives. On Fri, Nov 14, 2014 at 3:11 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3133/. > > CogVM binaries as per VMMaker.oscog-eem.934/r3133 > These VMs should be functionally identical to the 3126 VMs; the core VM > differs > only in having been compiled from generated source that has been > refactored to > enable convenient 32-bit to 64-bit Spur image bootstrap. I'm building and > releasing them mostly to test that refactoring. However, there is new DNS > support on Windows and SSL support on Unix. See below. > > Simulator/Slang: > Refactor to allow 32-bit and 64-bit Spur to coexist > in the simulator, thereby allowing a 64-bit bootstrap. > > Replace direct use of BytesPerWord, ShiftForWord, BytesPerOop and > BaseHeaderSize > with sends of wordSize, shiftForWord, bytesPerOop & baseHeaderSize > respectively. > Make sure these are still output as the manifest constants in the > generated C. > Eliminate use of bytesPerSlot in favour of bytesPerOop. The use of sends > is > similar to those in trunk VMMaker, but I don't have time to merge. Sorry > :-(. > > Work-around use of sends for bytesPerOop in e.g. > generateToByDo:on:indent: and > users of isConstantNode:valueInto:. > > Do a better job at inlining via inlineCodeOrNilForStatement:in:. Comment > in > isNode:substitutableFor:inMethod:in: explains. > > Eliminate generic VM_LABEL support, labelling only the bytecodes in > interpret. > > Eliminate use of LargeContextSize in the stack and cog VMs. Alas haven't > yet > eliminated the frame offset constants such as FoxCallerSavedIP et al. We > only > need one of the two word sizes of interpreter to be executable in the > bootstrap. > > And remember to generate the GdbARMPlugin > > Add accessorDepths for the exported browser plugin primitives for Spur. > > Merge Levente's recent changes to DNS lookup on Windows and SSL on Unix. > See > http://squeakvm.org/cgi-bin/viewvc.cgi/squeak?view=revision&revision=2249 > http://bugs.squeak.org/view.php?id=7824 > > Have the Unix & Mac VMs print the process id and working directory when > blocking > on error or assert fail. Add scripts for the ARM VM archives. > -- > best, > Eliot > -- best, Eliot

Nov. 16, 2014

Re: [Pharo-dev] ValueHolder analysis

by Igor Stasenko

On 15 November 2014 22:49, stepharo <stepharo(a)free.fr> wrote: > I get dizzy (may be time to go to sleep) but I wonder > why do we need to check first the the window changed and after that it got > closed? > Especially since whenWindowChanged: presuppose that we have access to > window. > Am I missing something? > > self whenWindowChanged: [ :w | > w whenClosedDo: [ self clear ] ]. > > > ComposableModel>>whenWindowChanged: aBlock > window whenChangedDo: aBlock > > > WindowModel>>whenClosedDo: aBlock > > isClosedHolder whenChangedDo: [:value | > value ifTrue: [ aBlock value ] ] > > i am lost with this code. i cannot understand what is it for? because by construction you start from building GUI representation of your model.. in this case - you create a controller - and create a window (or widget AKA presenter) connected to it if you wanna present your model differently, you just start from fresh controller/presenter pair but changing the presenter while keeping controller intact (hence whenWindowChanged:) ? in that case, if you really want that, you will need to wire all events from widget once you set it up.. and not just close events.. but all e.g.: self whenWindowChanged: [ :w | w whenClosedDo: [ ]. w whenKeyPressedDo: [..]. w whenInvalidUserDo: [..]. w whenSomethingWentWrongDo: [..]. w whateverHappensDo: [..]. ]. i don't know, maybe i don't see it clearly. just trying to understand. -- Best regards, Igor Stasenko.

Nov. 16, 2014

Re: [Pharo-dev] [NB] NativeBoost and optCoerceNilToNull

by Igor Stasenko

On 15 November 2014 22:39, stepharo <stepharo(a)free.fr> wrote: > Igor > > Could you document this part of NB? > Write one page on your old blog so that after we can turn it into a real > doc. > > > i'd prefer to not change documentation, but implementation to match the documentation. > > Stef > > On 15/11/14 22:28, Igor Stasenko wrote: > > > > On 15 November 2014 15:53, Max Leske <maxleske(a)gmail.com> wrote: > >> Once again Iâm struggling with NativeBoost. Iâm trying to use >> optCoerceNilToNull with this function: >> >> ^self call: #(LGitReturnCodeEnum git_commit_create( >> LGitId * theCommitId, >> LGitRepository repo, >> String update_ref, >> LGitSignature * theAuthor, >> LGitSignature * theCommitter, >> String message_encoding, >> String theMessage, >> LGitTree theTree, >> int parent_count, >> LGitCommit * parentsPointer)) options: #( optCoerceNilToNull ) >> >> The last argument can be NULL, per documentation, (no parents). >> LGitCommit is a subclass of NBExternalObject and apparently >> NBExternalObjctType>>pushAsPointer: does *not* use the optCoerceNilToNull >> option (the super implementation in NBExternalType>>pushAsPointer: however >> does). The upshot of course is that the call fails with âan instance of >> LGitCommit expectedâ. >> >> My questions: >> - The documentation says: >> >> >> "#optCoerceNilToNull" >> "passing nil as a pointer-type argument, converts it to C NULL â >> >> but apparently this doesnât apply to every pointer type. Should the >> documentation be updated? >> - Why does NBExternlObjectType not use optCoerceNilToNull? I donât want >> to use tricks to pass null if I donât have to. >> > > perhaps because it is not there? :) > So, lets add it. > > - Related: there are instances where even non-pointer arguments are >> allowed to be NULL. Why does optCoerceNilToNull only work for pointer types? >> >> > like what? Suppose the argument type is a structure, e.g > "struct foo bar", that is non-pointer type. What in this case the NULL > value for the structure? > > >> Igor! Help! :) >> >> Cheers, >> Max >> >> > > > -- > Best regards, > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

Nov. 16, 2014

VM fixes to review

by Ben Coman

I notice several VM fixes [1] submitted by Nicolas 6 months ago. They are categorized as Milestone=Later, so I'm bumping them here just in case these slipped through the cracks to get them into Pharo 4. [1] https://pharo.fogbugz.com/default.asp?pgx=LF&ixFilter=36 But then I think I remember that early in Pharo 4 cycle, the Pharo VM was aligned more closely with with Eliot's - so maybe some of these are already included? cheers -ben

Nov. 16, 2014

Re: [Pharo-dev] Julia vs Pharo

by Alexandre Bergel

Hi Serge! Thanks for sharing this. I indeed believe that scientific computing will play a big role in Pharo adoption by a large public Alexandre > On Nov 15, 2014, at 2:57 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > Hi all, > > I find a recent paper about Julia that might be appealing for people > interested in doing scientific computation in Pharo (like the > SciSmalltalk community) : http://arxiv.org/pdf/1411.1607v1.pdf > "Julia: A fresh approach to numerical computing" > > Julia is a new dynamic programming language for scientific programming > with much higher performance than R or Python. > > I found that some concepts are quite closed to Pharo in fact: > > - meta-programming and code generation > - arbitrary precision integer > - JIT compiler (based on LLVM) > - call to C API > > What is missing in Pharo at the moment: > - multiple dispatch > - arbitrary precision float > - dynamic dataflow type inference > - optional type annotations (maybe with pluggable type extensions for Pharo ?) > - special matrices types like spares or dense matrix, tri-diagonal, etc ... > - vectorization > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Help fight Ebola by joining the Computing for Ebola Challenge > http://bit.ly/1oEdBag > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 16, 2014

Re: [Pharo-dev] [NB] Undocumented NativeBoost options

by Max Leske

> On 15.11.2014, at 20:53, stepharo <stepharo(a)free.fr> wrote: > > > On 15/11/14 12:37, Max Leske wrote: >> I got a bit frustrated and ended up searching the source for â[\w]opt[[:upper]]â to find all NativeBoost options. Some of those options are in fact undocumented: >> >> optMayGC >> optProxyLabels >> optCdecl >> optReturnNullAsNil >> optStdcall >> optNonMovable >> optReserveCallgateSpace >> optDebug >> optNoAlignment >> optEmitCall >> optNoCleanup >> optCheckFailOnEveryArgument >> optStringOrNull >> WinUnicode >> >> NBFFICallout>>defaultOptions documents most options but refers to NBFFICallout>>allOptions, wich does not exist. Most of the above options can be considered internal, I guess, but the one option I needed (âoptStringOrNullâ) isnât documented anywhere. I had to step through the execution to find out why my function call wasnât working (because I was trying to use âoptCoerceNilToNullâ and didnât know that strings need a special option). >> >> Iâd be very thankful if these options would be included in the documentation. > Which documentation? There is one? Well, thereâs a bit of documentation on Google code and then thereâs NBFFICallout class>>defaultOptions, which has some comments. Thatâs it basically. > And yes this pisses me off. > >> >> Note: âWinUnicodeâ is used by the Windows code in a couple of places, even though the option name is not valid, according to NBNativeCodeGen>>parseOptions: >> >> Cheers, >> Max >> > >

Nov. 15, 2014

Re: [Pharo-dev] Configurations and Github for a specialised configuration browswe

by kilon alios

yes I was thinking about git tags too, but since I have never tried this with pharo or other smalltalk I had my concerns how well it would work. I am really glad it works for you, that means it will works for me as well if I want some versioning for users. I also like the github url very much, simple concise and direct to the point. Thanks for the link too, I am reading it now. On Sun, Nov 16, 2014 at 12:03 AM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > > > On Sat, Nov 15, 2014 at 9:54 AM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> Travis seems like an overkill for me right now. Sure if I was bombarded >> by pull requests from other developers but in reality I work alone . But I >> will definitely keep it in mind in case my projects become so popular that >> people start to send me pull requests regularly. >> > > Makes sense. > > >> >> All I wanted was an easy way to install code from github to pharo without >> the need to install git and you gave me that. Next step is to see how I >> would integrate github with pharo better, should I use Configuration >> versions or is it better to use branches ? I am more orientated towards >> branches. >> > > With git I think that configurations are really no longer necessary ... I > prefer to use branches to isolate development work from the master branch > (topic branches) and then use tags to identify release points ... with > travis-ci validating the commits, I can do continuous deployment on the > master branch ... For Seaside31 we are using tags to stay in sync with the > mcz repository so the tags are useful when folks are used to talking about > useing a particular version of Seaside31. To replace symbolic versions > (like #release3 or #release3.1) we have introduced pattern matching for > tags. You can use the following github url to load the latest version of > 3.1: > > github://GsDevKit/Seaside31:3.1.?/repository > > >> I have stared your repos to make sure I get keep updated in any progress >> you make. I plan also to go back and re read that metacello chapter to >> better understand metacello. >> > > Take a look at the Metacello User Guide[1] as well for information about > using the Metacello Scripting API. > > [1] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > > >> >> Thank you very much for your hard work, keep rocking :) >> >> > Haha, my pleasure! > > Dale > >

Nov. 15, 2014