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

Re: [Pharo-project] Status of ToolBuilder

by Frank Shearar

On 16 November 2011 21:58, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Wed, Nov 16, 2011 at 1:53 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: >> >> On Nov 16, 2011, at 6:31 PM, Lukas Renggli wrote: >> >> >>> I was kind of surprised that ToolBuilder is still part of Pharo. >> >> >> >> where? >> >> Because we removed it. >> > >> > It is contained in the Polymorph packages in Pharo 1.3, but it missing >> > some and has additional other features compared to the version in >> > Squeak. >> > >> > I was asking because OmniBrowser in Squeak is now using ToolBuilder, >> > the code works with a few changes in Pharo 1.3 too. >> >> >> Does Toolbuilder make sense? To me it looked like yet another >> compatibility >> layer that does not bring anything (other than forcing anyone to use >> something >> that has to be compabtible to MVC). > > In general it abstracts away the specific UI used to present a tool and I'd > say that was generally useful. Â Anyone wanting to experiment with a novel UI > could benefit from ToolBuilder. Â In Squeak trunk there's even the ability to > test it against Morphic and MVC. Â MVC is still useful for those trying to > build minimal images. It's also really useful for someone who knows just enough about Morphic to not want to know anything more about Morphic to still knock up a half-decent UI. I've found ToolBuilder useful for constructing new UIs, editing existing ones and being able to follow actions without needing to know much about about Morphic. frank >> >> Â Â Â Â Marcus >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> > > > > -- > best, > Eliot >

Nov. 16, 2011

Re: [Pharo-project] Status of ToolBuilder

by Eliot Miranda

On Wed, Nov 16, 2011 at 1:53 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Nov 16, 2011, at 6:31 PM, Lukas Renggli wrote: > > >>> I was kind of surprised that ToolBuilder is still part of Pharo. > >> > >> where? > >> Because we removed it. > > > > It is contained in the Polymorph packages in Pharo 1.3, but it missing > > some and has additional other features compared to the version in > > Squeak. > > > > I was asking because OmniBrowser in Squeak is now using ToolBuilder, > > the code works with a few changes in Pharo 1.3 too. > > > Does Toolbuilder make sense? To me it looked like yet another compatibility > layer that does not bring anything (other than forcing anyone to use > something > that has to be compabtible to MVC). > In general it abstracts away the specific UI used to present a tool and I'd say that was generally useful. Anyone wanting to experiment with a novel UI could benefit from ToolBuilder. In Squeak trunk there's even the ability to test it against Morphic and MVC. MVC is still useful for those trying to build minimal images. > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > > -- best, Eliot

Nov. 16, 2011

Re: [Pharo-project] Status of ToolBuilder

by Marcus Denker

On Nov 16, 2011, at 6:31 PM, Lukas Renggli wrote: >>> I was kind of surprised that ToolBuilder is still part of Pharo. >> >> where? >> Because we removed it. > > It is contained in the Polymorph packages in Pharo 1.3, but it missing > some and has additional other features compared to the version in > Squeak. > > I was asking because OmniBrowser in Squeak is now using ToolBuilder, > the code works with a few changes in Pharo 1.3 too. Does Toolbuilder make sense? To me it looked like yet another compatibility layer that does not bring anything (other than forcing anyone to use something that has to be compabtible to MVC). Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 16, 2011

Re: [Pharo-project] SystemChangeNotifier and Traits

by Eliot Miranda

On Wed, Nov 16, 2011 at 1:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > + 1 > > and we should remove the old ones and a lot of old abstraction > MethodReference, > PseudoClass, FilePackage, and a lot more > I hope that we will get into that mode soon. > PseudoClass, FilePackage, may indeed be poor. But IMO MethodReference is central and extremely useful. > Stef > > On Nov 16, 2011, at 3:55 PM, Fernando Olivero wrote: > > > Please note that eventually the system is going to be using solely > > System announcements, instead of the old mechanism in place right now. > > > > Did you try hooking up to the SystemAnnouncements? > > > > For examples, check out Nautius. > > > > Fernando > > > > > > > > On Tue, Nov 15, 2011 at 9:02 PM, ezequiel lamonica > > <lamonicaezequiel(a)gmail.com> wrote: > >> Hello again, > >> > >> Now the problem is when I create a class that use Traits, > >> SystemChangeNotifier sends two messages to report this creation: 1st for > >> class added without traits, and 2nd for class modified to use this > trait. > >> And this last message has Object as old class instead of ClassForTesting > >> without traits. > >> > >> For example: > >> > >> Object subclass: #ClassForTesting > >> uses: TSortable > >> instanceVariableNames: 'a' > >> classVariableNames: '' > >> poolDictionaries: '' > >> category: 'OOSCM-ClientImageTest' > >> > >> > >> Can I change those messages to use only one message that includes > traits? Is > >> not this better? > >> > >> What do you suggest? > >> > >> > >> > >> ----- > >> eze > >> -- > >> View this message in context: > http://forum.world.st/SystemChangeNotifier-and-Traits-tp4073962p4073962.html > >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >> > >> > > > > > -- best, Eliot

Nov. 16, 2011

Re: [Pharo-project] Status of ToolBuilder

by Lukas Renggli

>> I was kind of surprised that ToolBuilder is still part of Pharo. > > where? > Because we removed it. It is contained in the Polymorph packages in Pharo 1.3, but it missing some and has additional other features compared to the version in Squeak. I was asking because OmniBrowser in Squeak is now using ToolBuilder, the code works with a few changes in Pharo 1.3 too. >> Are there any users? Are there any plans to update it to match the >> version of Squeak? Is it encouraged to build UIs with ToolBuilder? > > no Â :) > We were brainstorming on valueHolder, Spec and UIBuilder a la VW with Benjamin and we got the > conclusions: > Â Â Â Â Specs are cool because the same application Model can propose multiple spec That has nothing to do with specs though, there are many other ways of how multiple views can work with or provided by the same model. In my experience specs often lack the necessary dynamics to build useful UIs. So a lot of glue code is necessary to assemble the different parts. In the end I find it more convenient to just use the glue code (like in Seaside or ToolBuilder). > Â Â Â Â valueHolder are the building brick to be able to reuse the application model UI logic (and not just the UI widgets). I do not understand that point. Lukas -- Lukas Renggli www.lukas-renggli.ch

Nov. 16, 2011

Re: [Pharo-project] Slow text input?

by StÃ©phane Ducasse

>> > > I found the cause with a key remapper I use. I had tested it a couple weeks ago by 'disabling it' which apparently is rather > different than having it not in memory at all. In pharo or on mac? You think that this is something that change the event fed to the VM? > > Thanks for the help and no so much for the thread hijacking.

Nov. 16, 2011

Re: [Pharo-project] Slow text input?

by StÃ©phane Ducasse

Indeed stfan and I would like to get the system even more robust to that kind of changes. In fact I would like to get a new class builder and a bootstrap but now I spent my day in meetings, writing reports and losing energy. Stef >> I NEVER had an image crash, of course i'm not stating that it cant >> crash, but would be nice to know how many people have to deal with >> image crashes and how often. > > In the course of one week: > > > $ grep STARTUP MyImage.35.changes | grep MyImage | wc -l > 45 > > What does that mean? I started the image 45 times. > And, no, I did not frequently save and quit the image, I just made it crash/unusable one way or another. > > How to deal with it? > > $ grep SNAPSHOT MyImage.35.changes | grep MyImage | wc -l > 145 > > But, well, what I did is certainly uncommon usage scenario. > People usually do not change #basicNew/#basicNew: or the Parser/Compiler/Encoder classes. > > So much for numbers > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >

Nov. 16, 2011

Re: [Pharo-project] Slow text input?

by StÃ©phane Ducasse

I had a funny crash when I did Editor := 'editor' in a class using a sharedPool with a class variable named Editor Now this is fixed in 1.4 but what we should do is to get the revert last accept in the emergency evaluator working again :) Stef On Nov 15, 2011, at 1:48 PM, Fernando Olivero wrote: > I NEVER had an image crash, of course i'm not stating that it cant > crash, but would be nice to know how many people have to deal with > image crashes and how often. > > Because, up to now, during my last 3 years of Pharo usage it never has > been a big issue for me. > > Fernando > > On Tue, Nov 15, 2011 at 1:37 PM, Peter Hugosson-Miller > <oldmanlink(a)gmail.com> wrote: >> I think the troll said he was leaving, so let's just all take a deep breath, be thankful for that, and move on. >> >> Positive energy is what we need here, feeding trolls drains us more than one would think, so as far as possible we should just try and ignore them. >> >> Carlo's answer was cool, too ;-) >> >> -- >> Cheers, >> Peter >> >> On Tue, Nov 15, 2011 at 1:26 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >> Currently, my Mac running 3 images. And it is hard to tell, but i >> think one of them runs maybe more than month , without hangs, freezes >> etc. >> Now, why i should trust your words (not backed with anything serious) >> that the software i use is unstable, when >> i using it every day and it works well for me? >> >> On 15 November 2011 12:18, Guido Stepken <gstepken(a)googlemail.com<mailto:gstepken@googlemail.com>> wrote: >>> Ok, if it helps you to understand, that unstable software is quite useless for anybody ... will do that! >>> >>> Guido Stepken >>> >>> Am 15.11.2011 um 12:05 schrieb Marcus Denker <marcus.denker(a)inria.fr<mailto:marcus.denker@inria.fr>>: >>> >>>> >>>> On Nov 15, 2011, at 8:00 AM, Guido Stepken wrote: >>>> >>>>> I think, programming, refactoring a peace of software has very much to do with model theory, LÃ¶wenheim-Skolem theory (related to fixed point theorem). >>>>> >>>>> Good programmers migrate code, addon's from one stable, consistent state to the other. These "stable states" are expressed in release numbers. >>>>> >>>>> What are you doing? Don't know! >>>> >>>> So why don't you then just unsubscribe from the mailinglist? >>>> >>>> We clearly are not up to your standards. And this will not change. >>>> >>>> I think there is no way that we can work constructively together, so the best for all is that you just go away. >>>> and everyone is happy. (you, too!) >>>> >>>> You can refactor according to Skolem, we refactor how we like it, and everyone is happy. >>>> >>>> Marcus >>>> >>>> >>>> -- >>>> Marcus Denker -- http://marcusdenker.de >>>> >>>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

Nov. 16, 2011

Re: [Pharo-project] Slow text input?

by StÃ©phane Ducasse

Sean this is really strange because we are all on mac and we use the 1.3 daily and it does not have such problems. I mean we plan to build a company around moose and pharo and we are working hard on that so you imagine easily that we would not if we could not edit code. Stef On Nov 15, 2011, at 3:31 AM, Sean T Allen wrote: > Hi all, > > I opened an old 1.2.1 image and text input was incredibly slow. > > I tried the latest one click and text input is very slow and jerky. > > Has anyone else ever experienced something like this on a Mac? > Its really frustrating. Every pharo image I have is seemingly unusable. > > -Sean-

Nov. 16, 2011

Re: [Pharo-project] Headless PetitParser

by StÃ©phane Ducasse

Thanks Alberto Documentation and sharing are underestimated in our community. What is simple for you may be complex for somebody else and the inverse, we are all more powerful together :) Stef On Nov 16, 2011, at 9:25 AM, Alberto Bacchelli wrote: > > StÃ©phane Ducasse wrote: >> >> can you give an example so that people can learn too? >> > > Sure. > > So I have a simple bash script that calls the vm, the image, and the script: > > ----------------bash script----------- > #!/bin/bash > > export AN_ENVIRONMENT_VARIABLE=somevalue > export SCRIPT_LOG_FILE=afilename > > > "$pharovm_dir"/squeak -plugins "$pharovm_dir" -encoding Latin1 -headless > "$pharo_image" "$smalltalk_script" && exit 0 > echo Something bad happened! > exit 1 > ---------------------------------------- > > the $smalltalk_script is an .st file with the code to be executed (an > example later). > environment variables, such as AN_ENVIRONMENT_VARIABLE and SCRIPT_LOG_FILE, > are useful to pass some info to the smalltalk script in an easy way, here we > use SCRIPT_LOG_FILE to save some script's output to a file. > > Here I put a very simple example based on what I did: > > > ----------------pharo script (aka $smalltalk_script)----------- > [| fs environment pid | > environment := OSProcess thisOSProcess environment. > pid := OSProcess thisOSProcess pid. > > someValue := (environment at: 'AN_ENVIRONMENT_VARIABLE'). > fs := FileStream forceNewFileNamed: (environment at: 'SCRIPT_LOG_FILE'). > > loggingBlock := [:message | > fs nextPutAll: TimeStamp now asString, ' [', pid asString, '] ' . > fs nextPutAll: message; nextPut: Character lf.]. > > loggingBlock value: 'Starting script with ', someValue. > > "do some interesting stuff here" > "..." > > Smalltalk snapshot: false andQuit: true.] on: Error do: [:err | OSProcess > thisOSProcess stdErr nextPutAll: err asString; nextPut: Character lf. > Smalltalk snapshot: false andQuit: true.] > ------------------------------------------ > > A few comments: > - with "OSProcess thisOSProcess environment" you can access environment > variables as a dictionary (that's why I use them instead of command line > arguments) > - "OSProcess thisOSProcess pid" gives you the pid of your process, in this > way I can make a unix-like log file > - "Smalltalk snapshot: false andQuit: true." closes the image correctly at > the end of your script and does NOT save the state on the image. > - "[...] on: Error do: [:err | OSProcess thisOSProcess stdErr nextPutAll: > err asString; nextPut: Character lf. Smalltalk snapshot: false andQuit: > true.]" is _VERY_ useful to debug your code. Any time there is an error in > the main block, it catches it and prints the message to the console using > the standard error. This is essential to be able not to spend ages in trying > to understand what went wrong with your script. > > That's all. I hope it's useful to someone. > > Cheers, > Alberto > > > -- > View this message in context: http://forum.world.st/Headless-PetitParser-tp3994446p4075649.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 16, 2011