October 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Spec: scaling imageModels

by stepharo

Hi matteo Please open a bug entry and submit a fix and there is a good chance that your enhancements will be added to Pharo. We cannot crawl the mails and do that in addition to all the rest. :) Stef

Oct. 20, 2016

new themoosebook.org - work in progress

by Tudor Girba

Hi, I am working on a new The Moose Book. You can see the current draft here: http://themoosebook.org In the current form, it covers about 40% of what I want to have at the end. My target is to get a first complete version ready until Spring 2017. The book targets Moose 6.1, although most parts will work with Moose 6.0. The book is written in Pillar. A secondary goal for this book is to build a book editor with tools in Pharo. The current book was generated directly from Pharo without using the command line. The current code is in book GitHub repository, but the end goal is to have these tools working separately from the book. Please let me know what you think. The book repo is here: https://github.com/girba/themoosebook Cheers, Doru -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

Oct. 20, 2016

Re: [Pharo-users] [Seaside] [ANN] ZÃ¼rich Smalltalk Meetup Nov 8th, 2016

by Esteban Lorenzano

> On 19 Oct 2016, at 22:55, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Michal, > > This sounds quite exciting ... I was wondering how you were getting on with Tugrik+Mongo+Voyage and now I know :) > > I would be very interested in helping you in any way that I can, just let me know. > yes, me too :) Esteban > Dale > > On 10/19/2016 01:01 PM, Michal Balda wrote: >> Hi, >> the short answer is: not yet. >> >> The back story is: We have been experimenting with GemStone and Tugrik at work. While Tugrik appears to work very well (even though it is new and not yet finished), I found the overall architecture (Tugrik+Mongo+Voyage) a bit complicated. Tugrik is meant to be a replacement for Voyage-Mongo but actually uses parts of its implementation and behavior. I understand that it does so to mimic Voyage-Mongo so that switching from Mongo to GemStone is relatively painless. That does not fit our use case though - we don't need a replacement for Mongo since we haven't used it in the first place. We would also like to have something that we could possibly maintain ourselves, should the priorities of Esteban or Dale change in a few years (I don't want this to sound negative, I am sure they would not drop the support just because they want to, but I understand they are very busy and for us it is a certain risk we would like to mitigate). >> >> While playing with Tugrik I came up with a few ideas so I started a clean Pharo image with the following task in mind: find a way of getting objects from Pharo to GemStone and back, as simply as possible, without any unnecessary dependencies. In other words, I wanted to see if I could create a simpler Pharo-to-GemStone persistence solution than the existing Tugrik+Mongo+Voyage stack. As of now it's still in an early phase but I already have something that could work. For the meetup in ZÃ¼rich I want to have something to show (a small demo), or, if I run into any conceptual issues, to have a topic for discussion if anyone's interested. >> >> I won't release it publicly until I am sure it works well. But I can guarantee you that if anything exciting does emerge, this mailing list will learn about it. It will definitely not be exclusive for the people who attend the meetup. I just want to use the opportunity of the meetup to get early feedback and/or input, maybe it will trigger a discussion about important issues that I haven't thought about yet. I am not at all a GemStone expert so the possibility is there. >> >> >> Michal >> >> >> >> On 18.10.2016 14:38, Mariano Martinez Peck wrote: >>> Hi, >>> >>> I would love to be in Zurich, but I obviously can't :( >>> So... is there a way to get some more info about that "Gemstone-based persistence framework for Pharo"? And who is Michal? Last name? >>> >>> Thanks, >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> >> >

Oct. 20, 2016

Re: [Pharo-users] CodeGenerator, your opinions?

by HernÃ¡n Morales Durand

Thank you Otto, I had a look and it seems a nice implementation (couldn't load into the image but using the Monticello Browser) Cheers, HernÃ¡n 2016-10-19 0:44 GMT-03:00 Otto Behrens <otto(a)finworks.biz>: > > Do you mean internal or embedded DSL? I am open to write an DSL if > > facilitates the job, the thing with the Trevor's paper is that he > defines 6 > > implementations of FSM's (and in each implementation he considers several > > issues leading to sub-implementations) so I would like a DSL which let me > > express different implementations for the same FSM. Plus there are FSM > > implementations out there: HotDraw, Connectors, MIDIInputParser, > XMIReader, > > SState, etc. I think a "correct" DSL would enable to define any of them > > right? > > I just meant some syntactically terse way of expressing a state > machine so that one can see the logic clearly. Representing a state > machine in a graphical way is ideal. We did this once, but the problem > is to make the state machine definition resilient to refactorings and > changes to the code. What I mean is that compiling something into code > is a one way thing; to keep it maintained, one would like to "reverse > compile" and draw the state machine from code. > > A "correct" DSL would be something like a Harel state diagram, which > should be able to express most requirements. > > I attach our state package, if you're interested. Not directly one of > the approaches in Trevor's paper. Perhaps another option. I would like > to extend it to use guards and actions and more. > > > The approach I am using now is a parametrized code generator, using > > templates (not in the form of T4 templates), so it's a long way. > > Maybe Helvetia could help? > > Out of my depth here; will have to read a lot more. > > > > > > >> > >> On Tue, Oct 18, 2016 at 9:29 AM, Julien Delplanque <julien(a)tamere.eu> > >> wrote: > >> > Hello, > >> > > >> > A generator for the visitor design pattern: > >> > - Generate methods in visited objects: VisitedObject>>#accept: (with > the > >> > selector name configurable) > >> > - Generate empty methods (or methods with a "self > >> > subclassResponsability" if > >> > an abstract visitor is generated) > >> > called in #accept: methods of VisitedObjects in the Visitor i.e > >> > Visitor>>#acceptVisitedObject: (with the selector > >> > name configurable again). > >> > > >> > Each time this design pattern has to be used, it is annoying to write > by > >> > hand all these methods. > >> > > >> > Regards, > >> > > >> > Julien > >> > > >> > > >> > On 18/10/16 07:24, HernÃ¡n Morales Durand wrote: > >> >> > >> >> Hi guys, > >> >> > >> >> I am writing a code generator, doing a few iterations right now. > >> >> I want your opinion, which most useful thing would you like to be > >> >> generated > >> >> automatically? It could be a pattern, an idiom, another language... > >> >> > >> >> For example my own wish (roadmap) list: > >> >> > >> >> - A "settings framework" settings class generator. > >> >> - A state machine generator (based in the excellent paper of Trevor > P. > >> >> Hopkins) > >> >> - A Spec UI generator. > >> >> > >> >> Let me know your thoughts. > >> >> > >> >> Cheers, > >> >> > >> >> HernÃ¡n > >> >> > >> > > >> > > >> > > >

Oct. 20, 2016

Re: [Pharo-users] [Seaside] [ANN] ZÃ¼rich Smalltalk Meetup Nov 8th, 2016

by Mariano Martinez Peck

On Wed, Oct 19, 2016 at 5:01 PM, Michal Balda <lists(a)michalbalda.cz> wrote: > Hi, > the short answer is: not yet. > > The back story is: We have been experimenting with GemStone and Tugrik at > work. While Tugrik appears to work very well (even though it is new and not > yet finished), I found the overall architecture (Tugrik+Mongo+Voyage) a bit > complicated. Tugrik is meant to be a replacement for Voyage-Mongo but > actually uses parts of its implementation and behavior. I understand that > it does so to mimic Voyage-Mongo so that switching from Mongo to GemStone > is relatively painless. That does not fit our use case though - we don't > need a replacement for Mongo since we haven't used it in the first place. > We would also like to have something that we could possibly maintain > ourselves, should the priorities of Esteban or Dale change in a few years > (I don't want this to sound negative, I am sure they would not drop the > support just because they want to, but I understand they are very busy and > for us it is a certain risk we would like to mitigate). > > While playing with Tugrik I came up with a few ideas so I started a clean > Pharo image with the following task in mind: find a way of getting objects > from Pharo to GemStone and back, as simply as possible, without any > unnecessary dependencies. In other words, I wanted to see if I could create > a simpler Pharo-to-GemStone persistence solution than the existing > Tugrik+Mongo+Voyage stack. As of now it's still in an early phase but I > already have something that could work. For the meetup in ZÃ¼rich I want to > have something to show (a small demo), or, if I run into any conceptual > issues, to have a topic for discussion if anyone's interested. > > I won't release it publicly until I am sure it works well. But I can > guarantee you that if anything exciting does emerge, this mailing list will > learn about it. It will definitely not be exclusive for the people who > attend the meetup. I just want to use the opportunity of the meetup to get > early feedback and/or input, maybe it will trigger a discussion about > important issues that I haven't thought about yet. I am not at all a > GemStone expert so the possibility is there. > > > Hi, OK, I understand. Thanks for the explanation. BTW, for your implementation, do you use ServerBlocks [1] ? It may be handy otherwise. Best regards, [1 ] https://github.com/GsDevKit/GsDevKit_home/blob/master/docs/articles/gsDevKi… > Michal > > > > On 18.10.2016 14:38, Mariano Martinez Peck wrote: > > Hi, > > I would love to be in Zurich, but I obviously can't :( > So... is there a way to get some more info about that "Gemstone-based > persistence framework for Pharo"? And who is Michal? Last name? > > Thanks, > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Oct. 20, 2016

Re: [Pharo-users] How do I debug a MNU in Pharo-6.0

by Dale Henrichs

It looks like some "Failed magic" is involved here. A bit of the stack for your viewing pleasure: MessageNotUnderstood: receiver of "ifTrue:ifFalse:" is nil UndefinedObject(Object)>>doesNotUnderstand: #ifTrue:ifFalse: STONWriter>>ExecuteUnOptimizedIn: UndefinedObject(Object)>>mustBeBooleanInMagic: UndefinedObject(Object)>>mustBeBoolean STONWriter>>encodeString: Perhaps this is a Pharo6.0 bug -- triggered by my bug in STONWriter>>encodeString: Travis is running headless and presumably the error/notification/exception handling is a bit different running headless? Dale On 10/19/2016 03:35 PM, Dale Henrichs wrote: > > I am trying to debug a problem that showed up loading my version of > STON into Pharo-6.0. ON Travis, I see the error message[1]: > > MessageNotUnderstood: receiver of "ifTrue:ifFalse:" is nil > > The code is loading and passing tests in Pharo-5.0, 4.0, 3.0 and > several versions of GemStone, so I am interested in bringing up a > debugger... > > I cloned git@github.com:GsDevKit/ston.git and checked out the gs_port > branch into the directory > /export/foos1/users/dhenrich/dev/_home/server/stones/m_340/git/ston. > > But when I run the following code in a Pharo-6.0 image using the > Playground by pressing the green arrow: > > Metacello new > baseline: 'Ston'; > repository: > 'gitfiletree:///export/foos1/users/dhenrich/dev/_home/server/stones/m_340/git/ston/repository'; > load: #( 'UTF8' 'Tests') > > I do not get the expected MNU in a debugger -- but I do see a bunch of > infos popping up during the execution but they fade too quickly for me > to actually read them --- there were 8 or more popups --- and I got > the impression that they involved the ifTrue:ifFalse:, but danged if I > know how to debug the problem ... > > I must have missed the memo that tells me how to get a debugger up in > Pharo-6.0 ... > > Any advice? > > Dale > > [1] https://travis-ci.org/GsDevKit/ston/jobs/169029017#L435 >

Oct. 19, 2016

Re: [Pharo-users] CodeGenerator, your opinions?

by HernÃ¡n Morales Durand

Hi Stef 2016-10-19 17:29 GMT-03:00 stepharo <stepharo(a)free.fr>: > Hernan > > What is the input you take to generate magritte? > Something like this: CGStMagritte uniqueInstance inputClass: ModelClass1; targetClass: ModelClass1; setBooleanAttributes: 'instVar1' label: 'label iVar1' priority: 10; setDateAndTimeAttributes: 'instVar2' label: 'label Date and Time' priority: 20; setDateAttributes: 'instVar3' label: 'label Date' priority: 30; setFileAttributes: 'iVarFile' label: 'label File' priority: 40; setMemoAttributes: 'iVarMemo' label: 'label Memo' priority: 50; setMultiOptionAttributes: 'iVarMultiOption' label: 'label Multi Option' priority: 60; setNumberAttributes: 'iVarInteger' label: 'label Integer' priority: 70; generateMethods. Smalltalk tools browser openOnClass: ModelClass1. self inform: 'Done'. which generates ModelClass1>>descriptionInstVar1 <magitteDescription> | tmp2 | tmp2 := MABooleanDescription new. tmp2 accessor: #instVar1; label: 'label iVar1'; priority: 10. ^ tmp2 yourself ModelClass1>>descriptionInstVar2 <magitteDescription> | tmp2 | tmp2 := MADateAndTimeDescription new. tmp2 accessor: #instVar2; label: 'label Date and Time'; priority: 20. ^ tmp2 yourself and so on. Lionel would like to have a kind of Crud on top of Pharo and it would be > good for business. > Cool, hope he finds useful the code generator > Stef > > Le 18/10/16 Ã 18:07, HernÃ¡n Morales Durand a Ã©crit : > > > 2016-10-18 9:35 GMT-03:00 Lionel Akue <lionelakue(a)gmail.com>: > >> Great! >> >> We had the same idea :) >> >> > Let me know if we can join forces to speed uo things. > > >> The first requirements I wrote was to generate Spec UI directly. But I >> rather chose to make Magritte compatible with Spec. >> >> So from the Magritte description, we could generate Spec, Seaside ... >> >> > The CodeGenerator I wrote already generates Magritte code. If you load it > in Pharo 5 > > Gofer it > smalltalkhubUser: 'hernan' project: 'CodeGenerator'; > configuration; > loadDevelopment. > > Have a look at the usage examples: > > #exampleMagritteDescriptionCreation1 > #exampleMagritteDescriptionCreation2 > #exampleMagritteDescriptionCreation3 > > If you have suggestions I would like to read. > > HernÃ¡n > > >> Lionel >> >> 2016-10-18 14:20 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: >> >>> Hi Hernan, >>> >>> I wrote some time ago two basic code generators (both in Pharo) from >>> UML-ified FAMIX for a particular user (so there are some domain-specific >>> patterns), >>> one for Pharo syntax ( https://github.com/OpenPonk/cl >>> ass-editor/blob/master/docs/code-generation/uml-to-code.md ) >>> and one for VW syntax ( https://github.com/OpenPonk/cl >>> ass-editor/blob/master/docs/vw-code-generation/pim-psm.md ) >>> >>> (the code is here https://github.com/OpenPonk/cl >>> ass-editor/tree/master/repository/DynaCASE-Generator.package and here >>> https://github.com/OpenPonk/class-editor/tree/master/reposit >>> ory/UML-CodeGenerator.package ) >>> >>> The most pain I had was with expressing templateable code to which I >>> could just plug specific data, I wanted to look at QVT but didn't have the >>> time yet. >>> But it would be interesting to see if your generator could address such >>> issues; plus soon I want to iterate on my generators to have more live >>> interaction (so the code is generated on the fly as the model is created, >>> although I am using Pharo Refactoring engine for now, which is also quite >>> powerful.) >>> >>> Addionally, Lionel (in cc) is working on some meta system generating >>> classes with magritte descriptions. >>> >>> So it would be cool if we could have some really cool generator that >>> could do many cool things. :) >>> >>> Peter >>> >>> On Tue, Oct 18, 2016 at 02:24:28AM -0300, HernÃ¡n Morales Durand wrote: >>> > Hi guys, >>> > >>> > I am writing a code generator, doing a few iterations right now. >>> > I want your opinion, which most useful thing would you like to be >>> generated >>> > automatically? It could be a pattern, an idiom, another language... >>> > >>> > For example my own wish (roadmap) list: >>> > >>> > - A "settings framework" settings class generator. >>> > - A state machine generator (based in the excellent paper of Trevor P. >>> > Hopkins) >>> > - A Spec UI generator. >>> > >>> > Let me know your thoughts. >>> > >>> > Cheers, >>> > >>> > HernÃ¡n >>> >> >> > >

Oct. 19, 2016

How do I debug a MNU in Pharo-6.0

by Dale Henrichs

I am trying to debug a problem that showed up loading my version of STON into Pharo-6.0. ON Travis, I see the error message[1]: MessageNotUnderstood: receiver of "ifTrue:ifFalse:" is nil The code is loading and passing tests in Pharo-5.0, 4.0, 3.0 and several versions of GemStone, so I am interested in bringing up a debugger... I cloned git@github.com:GsDevKit/ston.git and checked out the gs_port branch into the directory /export/foos1/users/dhenrich/dev/_home/server/stones/m_340/git/ston. But when I run the following code in a Pharo-6.0 image using the Playground by pressing the green arrow: Metacello new baseline: 'Ston'; repository: 'gitfiletree:///export/foos1/users/dhenrich/dev/_home/server/stones/m_340/git/ston/repository'; load: #( 'UTF8' 'Tests') I do not get the expected MNU in a debugger -- but I do see a bunch of infos popping up during the execution but they fade too quickly for me to actually read them --- there were 8 or more popups --- and I got the impression that they involved the ifTrue:ifFalse:, but danged if I know how to debug the problem ... I must have missed the memo that tells me how to get a debugger up in Pharo-6.0 ... Any advice? Dale [1] https://travis-ci.org/GsDevKit/ston/jobs/169029017#L435

Oct. 19, 2016

Re: [Pharo-users] [Seaside] [ANN] ZÃ¼rich Smalltalk Meetup Nov 8th, 2016

by Esteban A. Maringolo

2016-10-19 17:01 GMT-03:00 Michal Balda <lists(a)michalbalda.cz>: > While playing with Tugrik I came up with a few ideas so I started a clean Pharo image with the following task in mind: find a way of getting objects from Pharo to GemStone and back, as simply as possible, without any unnecessary dependencies. In other words, I wanted to see if I could create a simpler Pharo-to-GemStone persistence solution than the existing Tugrik+Mongo+Voyage stack. As of now it's still in an early phase but I already have something that could work. For the meetup in ZÃ¼rich I want to have something to show (a small demo), or, if I run into any conceptual issues, to have a topic for discussion if anyone's interested. Interesting... Will this work in a GemBuilder fashion? (getting replicas and forwarders), or will it work more like James Foster's Jade client for Dolphin that is, AFAIU, a text based protocol? Regards! Esteban A. Maringolo

Oct. 19, 2016

Re: [Pharo-users] Default working directory

by Vitor Medina Cruz

I think file writeStream of File does not honor FileSystem configuration. In the end of the message chain you have the primitive call "primOpen: fileName writable: writableFlag". Try changing your test code to this: testFileExists | file | file := FileSystem workingDirectory / 'asd.txt'. file writeStream close. self assert: file exists. file delete This should work. I don't know, however, if that is the best practice or not. On Wed, Oct 19, 2016 at 3:33 PM, wvzuilen <wvzuilen(a)gmail.com> wrote: > I've tried that. Like this: FileSystem disk workingDirectoryPath: Path / > 'Users/myusername/Desktop'. > As expected it changes my working directory, but the test mentioned in my > first post still fails. ?!? > > > > -- > View this message in context: http://forum.world.st/Default- > working-directory-macOS-tp4919393p4919408.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Oct. 19, 2016