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

Filetree and Git and Github

by kilon alios

I have been told that there are some problem with gitfiletree that make it not recommended for public consumption and recommendation to newcomers. I have been using not gitfiletree but filetree alone for the past week for my project Ephestos, because I am ok commiting to git via terminal/ https://github.com/kilon/phEphestos I have to congratulate people behind filetree it has been a smooth ride so far.I had no problems with it at all and I am using git in terminal for doing all the git commits and push etc. filetree also has been very succesful at some major refactoring I have done to Ephestos, I had to change the name of an entire class and I had to change methods to other classes . Filetree did an excellent job not just with the export to st file but actually git was able to see which files were deleted and which were renamed. That meant I did not have to do any git rm . However I do need to git add every time I add a new method or filetree creates a new file. Usually that is not a problem because I can see what files are not tracked by git with git status and copy paste their paths to git add. So I will say overall my commits have been a process of saving in monticello , git add, git commit and git push which exactly the same process I have used for when I was and still coding in python. So thank you for this tool , I got fed up with the slow downs of Smalltalkhub and all its problems and it feels great to be back at using github :) I will keep testing for a couple a months and then completely move to github . The only thing I noticed is that sometimes monticello slows down but that may well be a problem with Pharo 4.

Sept. 19, 2014

Re: [Pharo-dev] Versioner does not work on Pharo 4

by kilon alios

Well to kepp you updated , because I did not bother replying to my own thread since none seemed to care or have the same issue as me. I tried on windows again same error as macos on a fresh image by the way. So I know it must not be me. But now with a latest Pharo 4 image i get no errors in both Macos and Windows, so the bug apparently was fixed. That may explain why you get no error , maybe it was a bug in a specific release. The only things I am doing with pharo is 1) use dark theme 2) use free type font Arial on windows and Monaco on macos 3) use filetree for working with a git directory. On Fri, Sep 19, 2014 at 11:20 AM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > Hi Kilon, > > You error is strange. I use Versionner on Pharo 4.0 without any problem. > If I take a closer look at the stack trace, the error comes from the > MetacelloToolBox when Versionner asks for configuration classes. > What is really strange is that after this message sent, the stack shows > the execution goes through EphPyParser class(Object)>>mustBeBoolean. > I don't get why. > I tried in a fresh Pharo image to load Ephestos, create a config for it, > and got no problem. > Can you try to reproduce and give more information about the environment, > what you did? > > Thanks, > Christophe. > > Le 17 sept. 2014 Ã 16:57, kilon alios a Ã©crit : > > > So I tried today to open versioner to make a configuration for Ephestos > and i got this error > > > > RBMethodNode(Object)>>doesNotUnderstand: #asSequenceNode > > EphPyParser class(Object)>>mustBeBooleanInMagic: > > EphPyParser class(Object)>>mustBeBoolean > > MetacelloProjectRegistration class>>ExecuteUnOptimizedIn: > > EphPyParser class(Object)>>mustBeBooleanInMagic: > > EphPyParser class(Object)>>mustBeBoolean > > [ :cl | > > (answer includes: cl) > > ifFalse: [ > > (([ cl isMetacelloConfig ] > > on: Error > > do: [ :ex | ex return: false ]) and: [ cl name > asString beginsWith: 'ConfigurationOf' ]) > > ifTrue: [ answer add: cl ] ] ] in > MetacelloProjectRegistration class>>configurationClasses in Block: [ :cl | > ... > > OrderedCollection>>do: > > MetacelloProjectRegistration class>>configurationClasses > > MetacelloToolBox class>>configurationClasses > > MBConfigurationRoot>>configurationClasses > > MBConfigurationRoot>>configurations > > VersionnerSpecBrowser class>>imageConfigurations > > VersionnerSpecBrowser class>>open > > [ VersionnerSpecBrowser open ] in VersionnerSpecBrowser > class>>menuCommandOn: in Block: [ VersionnerSpecBrowser open ] > > BlockClosure>>cull: > > [ > > | selArgCount | > > "show cursor in case item opens a new MVC window" > > (selArgCount := selector numArgs) = 0 > > ifTrue: [ target perform: selector ] > > ifFalse: [ > > selArgCount = arguments size > > ifTrue: [ target perform: selector withArguments: > arguments ] > > ifFalse: [ target perform: selector withArguments: > (arguments copyWith: evt) ] ]. > > self changed ] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > in Block: [ ... > > BlockClosure>>ensure: > > CursorWithMask(Cursor)>>showWhile: > > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > > ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: > > ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: > > MouseButtonEvent>>sentTo: > > ToggleMenuItemMorph(Morph)>>handleEvent: > > MorphicEventDispatcher>>dispatchDefault:with: > > MorphicEventDispatcher>>dispatchEvent:with: > > ToggleMenuItemMorph(Morph)>>processEvent:using: > > MorphicEventDispatcher>>dispatchDefault:with: > > MorphicEventDispatcher>>dispatchEvent:with: > > MenuMorph(Morph)>>processEvent:using: > > > >

Sept. 19, 2014

Re: [Pharo-dev] Versioner does not work on Pharo 4

by Christophe Demarey

Hi Kilon, You error is strange. I use Versionner on Pharo 4.0 without any problem. If I take a closer look at the stack trace, the error comes from the MetacelloToolBox when Versionner asks for configuration classes. What is really strange is that after this message sent, the stack shows the execution goes through EphPyParser class(Object)>>mustBeBoolean. I don't get why. I tried in a fresh Pharo image to load Ephestos, create a config for it, and got no problem. Can you try to reproduce and give more information about the environment, what you did? Thanks, Christophe. Le 17 sept. 2014 Ã 16:57, kilon alios a Ã©crit : > So I tried today to open versioner to make a configuration for Ephestos and i got this error > > RBMethodNode(Object)>>doesNotUnderstand: #asSequenceNode > EphPyParser class(Object)>>mustBeBooleanInMagic: > EphPyParser class(Object)>>mustBeBoolean > MetacelloProjectRegistration class>>ExecuteUnOptimizedIn: > EphPyParser class(Object)>>mustBeBooleanInMagic: > EphPyParser class(Object)>>mustBeBoolean > [ :cl | > (answer includes: cl) > ifFalse: [ > (([ cl isMetacelloConfig ] > on: Error > do: [ :ex | ex return: false ]) and: [ cl name asString beginsWith: 'ConfigurationOf' ]) > ifTrue: [ answer add: cl ] ] ] in MetacelloProjectRegistration class>>configurationClasses in Block: [ :cl | ... > OrderedCollection>>do: > MetacelloProjectRegistration class>>configurationClasses > MetacelloToolBox class>>configurationClasses > MBConfigurationRoot>>configurationClasses > MBConfigurationRoot>>configurations > VersionnerSpecBrowser class>>imageConfigurations > VersionnerSpecBrowser class>>open > [ VersionnerSpecBrowser open ] in VersionnerSpecBrowser class>>menuCommandOn: in Block: [ VersionnerSpecBrowser open ] > BlockClosure>>cull: > [ > | selArgCount | > "show cursor in case item opens a new MVC window" > (selArgCount := selector numArgs) = 0 > ifTrue: [ target perform: selector ] > ifFalse: [ > selArgCount = arguments size > ifTrue: [ target perform: selector withArguments: arguments ] > ifFalse: [ target perform: selector withArguments: (arguments copyWith: evt) ] ]. > self changed ] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [ ... > BlockClosure>>ensure: > CursorWithMask(Cursor)>>showWhile: > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: > ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: > MouseButtonEvent>>sentTo: > ToggleMenuItemMorph(Morph)>>handleEvent: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > ToggleMenuItemMorph(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDefault:with: > MorphicEventDispatcher>>dispatchEvent:with: > MenuMorph(Morph)>>processEvent:using: >

Sept. 19, 2014

[Review: 11536] Add Stream >> printString:

by Max Leske

This issue was more of a discussion between Camillo and Sven. They never reached a conclusion, so please take a look. Iâve compiled the transcript below. The issue isnât easy to solve and maybe we can just close it as ânot importantâ. https://pharo.fogbugz.com/f/cases/11536/Add-Stream-printString ============ Camillo: This method should be added to avoid many asString sends. Example: stream nextPutAll: #('ABC') asString could be written as stream printString: #('ABC'). This is a common extension of the following pattern: stream nextPutAll: #('ABC') printString could be written as stream print: #('ABC'). ============ Sven: And what about #print: as implemented by Transcripts and SocketStreams ? It is shorter. Feels more familiar. ============ Camillo: #print: is already implement and doesn't solve the stream nextPutAll: foo asString case. Since you cannot simply write stream print: foo, since you get quotes added for Strings. Ok, I admit that with decent design you can avoid this, since it should almost never happen that you have a String or a non string object in the same variable, right? ============ Sven: Yeah, that String issue is a bit annoying sometimes. Indeed there is Stream>>#print: already. But look: ThreadSafeTranscript>>#print: anObject self nextPutAll: anObject asString how about that ? There is also #<< whose implementation is even weirder, but it is handy. The question remain: when do you want to mix Strings and other objects as arguments ? ============ Camillo: - #<< is basically a lazy combination of #nextPut: and #nextPutAll: - #print: should call #printOn: on the initial argument, which for strings defaults to storeOn: which I think is wrong, but I would hardly stand a chance changing that :P So my global goal here is to avoid any kind of asString sends while pushing stuff on a stream. Sadly this happens more often than I thought :/ ============ Sven: Maybe this discussion should happen on the mailing list ? Changing String>>#printOn: might be hard, but #<< is much more recent, no ? Could it not be changed to do what you want ? Like Streamm>><< anObject self nextPutAll: anObject asString Another point is that #asString is not so efficient, since it creates throwaway Strings.

Sept. 19, 2014

Re: [Pharo-dev] How production ready is Pharo on SQLServer?

by Tudor Girba

Here is how to load and install DBXTalk in Pharo 3.0: Gofer new smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; package: 'ConfigurationOfOpenDBXDriver'; load. #ConfigurationOfOpenDBXDriver asClass loadBleedingEdge. #NBPharoOpenDBX asClass installAsCurrent. Cheers, Doru On Fri, Sep 19, 2014 at 8:45 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yeahâ¦ I told you that dbxtalk site information is outdated (and never find > the time to update) > > you need to look here: > > http://smalltalkhub.com/#!/~DBXTalk/Configurations > > (or in the configuration browser) > > cheers, > Esteban > > On 19 Sep 2014, at 08:00, Stephan Eggermont <stephan(a)stack.nl> wrote: > > > Sebastian, that doesn't look like the correct one > > DBXTalk is on smalltalkhub > > > > https://ci.inria.fr/dbxtalk/ > > > > Stephan > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 19, 2014

Pharo books -> association

by stepharo

Hi guys I wanted to let you know that each time you buy a pharo book the small benefit is given to the association. Stef

Sept. 19, 2014

Re: [Pharo-dev] How production ready is Pharo on SQLServer?

by Esteban Lorenzano

yeahâ¦ I told you that dbxtalk site information is outdated (and never find the time to update) you need to look here: http://smalltalkhub.com/#!/~DBXTalk/Configurations (or in the configuration browser) cheers, Esteban On 19 Sep 2014, at 08:00, Stephan Eggermont <stephan(a)stack.nl> wrote: > Sebastian, that doesn't look like the correct one > DBXTalk is on smalltalkhub > > https://ci.inria.fr/dbxtalk/ > > Stephan >

Sept. 19, 2014

Re: [Pharo-dev] How production ready is Pharo on SQLServer?

by Stephan Eggermont

Sebastian, that doesn't look like the correct one DBXTalk is on smalltalkhub https://ci.inria.fr/dbxtalk/ Stephan

Sept. 19, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by stepharo

HI martin I'm because this is important to be able to learn Stef On 19/9/14 06:36, Martin McClure wrote: > On 09/15/2014 11:54 AM, Eliot Miranda wrote: > > >> Agreed. But one real problem with the Squeak/Pharo UI is the lack of >> native windows. There is an old project Graphics-External-Ffenestri but >> AFAICT it isn't being used. But there /is/ a really good prototype of a >> native window system above Squeak done by Vassili Bykov in Newspeak. >> The native windows contain morphs, but anything, including MVC, can be >> present. This provides native Win32 Windows (doing other platforms is >> merely work) /and/ the ability to snapshot and bring back up windows on >> a different platform (e.g. open in win32, snapshot and bring up in >> Squeak/Pharo Morphic windows, or vice verse), and the ability to do this >> dynamically. Is anyone motivated to port the Newspeak code back to >> Squeak/Pharo? >> >> >> If you're interested, contact me, or Vassili, or Bob Westergaard and ask >> about Brazil (think plumbing). >> > > By coincidence, this week I dusted off my project (shelved about a > year and a half ago) to port Brazil and Hopscotch to Smalltalk. And > have made some progress, though it's still very early stages. > > If anyone else is interested in helping move this forward more > quickly, let me know... > > Regards, > > -Martin > >

Sept. 19, 2014

Re: [Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos

by stepharo

Torsten we are 100% in sync on that vision :) Stef > Eliot wrote: >> We're getting there with fast. Tiny needs more definition, but the core Cog/Spur VM on Mac minus plugins and GUI >code is 568k, 506k code, 63k data; the newspeak VM which has fewer primitives but support for two bytecode sets is >453k, 386k code, 68k data. That includes the interpreter, JIT, core primitives and memory manager/GC. Add on >several k for the FFI, C library et al and a VM in a megabyte is realistic. Is that in the right ball park? > Yes, wet's my appetite :) > > Tiny means easy to download and use for scripting, no other dependencies > for the out of the box REPL experience. But still powerfull to built one on another > and scale up to large programs. > > Initially you provide just a simple VM executable for a "tiny smalltalk" (ts), for simple > things like: > > c:\myscripts\ts.exe -e 3+4 > 7 > > where ts.exe is the VM in a few kB including a small initial kernel image (as part of > the PE DATA section). It should be able to run scripts: > > c:\myscripst\ts.exe automate.st > > It should be possible to easily build components (either with or without the sources): > > ts.exe sunit.st -o sunit.sll > ts.exe sunit.st -noSource -o sunit.sll > > So you can either include other scripts > > ts.exe -i sunit.st mytests.st > > or link the previously built binary components to form something new. > > ts.exe -l junit.sll mytests.st > > But it should be possible to build another vm+image easily: > > ts.exe -i mykillerapp.st -o killerapp.exe > or ts.exe -l mykillerapp.sll -o killerapp.exe > > by writing a new PE file for Windows either including a new kernel image or a combined > one based on the already built-in initial kernel of the previous one. > So I can deploy a killerapp or reassemble it to form the next language version. > > SmallScript was very close to that and it was a nice thing to work with. > Especially since usually Smalltalk usually throws things out at the end - but > one never builds a house by carving it out of a rock. We need bricks to assemble. > > With the above scheme you could build components, some of them portable, others > explicitly non-portable as the code includes native calls. The later have to > be rebuilt on the other platform - so if you have good design abstractions you > can implement a UI lib on Windows and one on Mac. > > Some of the components are with the source code packaged in for debugging > (but not changeable), for closed source components you leave it out. > > And still it should support pinnable objects (not moved by GC for callouts), > sandboxing, Classes with UUIDs to allow for side by side loading/migration > and an extensible meta-scheme as this is where Smalltalk is still the hero of all > und metaprogramming will be our future. > > Also the VM should be available as a shared component - so it can run in-process > in other programs like a web browser. Always wished to write: > > <script type="text/tinyscript"> > BrowserLog write: 'HelloWorld'. > </script> > > directly in HTML. > > And this is only the beginning of the wish list... > >> Yep. But personally I think Fuel is better and just as fast. Certainly that's the parcels experience. >> - but still with the ability to bootstrap up to a full saveable image > Yes, Fuel would be an option. At least it would be platform independent. Not sure > about other options (quick loading by mapping component using memory mapped files etc.) > >> This we'll leave to the web framework designers, but it seems eminently doable no? > For sure. > > Bye > Torsten > > >

Sept. 19, 2014