August 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] line endings

by Sven Van Caekenberghe

We should indeed consider doing it, I believe Cuis has done the same. > On 04 Aug 2015, at 00:11, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Well yes, but Mac OS X (the first Mac using LF instead of CR) was released 14 years ago. > All *nixes uses LF and Windows CRLF. > So if we are not going to respect the platform, at least we could adhere to unix standards (LF). > > On Mon, Aug 3, 2015 at 9:41 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > I think this is for historical reason. > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Aug 3, 2015, at 3:57 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> Why does Pharo save everything with CR line endings? Literally nobody uses that. >> >> Peter > >

Aug. 4, 2015

Re: [Pharo-dev] Windows users, please test!

by Esteban Lorenzano

I uploaded yet another versionâ¦ it is hard to fix when things work for you :( in any case, I moved my development to a windows box and Iâm not having problems (yet). can you test the new SLICE? thanks! Esteban > On 03 Aug 2015, at 16:18, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-08-03 15:21 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > I made a new SLICE trying to fix the FT2 crash problem windows (and I think also linux?) are experiencingâ¦ can you please merge the SLICE for: > > https://pharo.fogbugz.com/f/cases/15633 <https://pharo.fogbugz.com/f/cases/15633> > > and test a bitâ¦ and inform any new problems? > > Iâm not a windows user but I tested the solution some time in a virtual imageâ¦ but we all know thatâs limited :) > > thanks! > Esteban > > > > > No, it still happens (attached crash.dmp) > Sometimes it crashes on startup and sometimes it starts up but uses only > non-ft fonts, as if FT was disabled. > > > <crash.dmp>

Aug. 4, 2015

Re: [Pharo-dev] Multiple syntax support in Pharo

by Esteban Lorenzano

Hi, AFAIK, this was Lukas phd thesis: Helvetia. http://scg.unibe.ch/research/helvetia <http://scg.unibe.ch/research/helvetia> cheers, Esteban > On 04 Aug 2015, at 10:48, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 04/08/2015 10:08, ClÃ©ment Bera a Ã©crit : >> Hello Pharoers, >> >> I'd like to do something a bit crazy and I think it's possible in Pharo >> so I'm asking for advises here. >> >> I would like to have packages / hierarchy of classes in Pharo that have >> methods written with a different syntax. >> >> I know that syntax coloring and most refactoring tools work on AST. So >> is it possible, for a given class, to override #parser or #parserClass >> class side in a similar way that you can override #compiler and >> #compilerClass, and from then on, the class methods will use this parser >> instead of RBParser to be parse its methods source code to the AST in >> the compilation chain and for syntax coloring (hence with full >> compatibility with the class browser) ? > > It depends on how the system browser is implemented, but it sounds doable. > > I would be able to do that fairly easily on AltBrowser, since commands (all menus and shortcuts, including refactorings) are delegated to the node you are using (i.e. the class, the method, the command) in the browser. Syntax coloring is sort of keyed to the node (i.e. a comment node doesn't do syntax coloring the way a method node does). > >> I am talking about another syntax that would be parsed to the same AST >> for now, though as the compiler can be changed too, I guess a complete >> separate compilation chain and AST could work fine if the AST has common >> APIs with RB for the refactoring browser and syntax coloring. > > No, that wouldn't work for refactoring. I believe RB apply refactorings by source code changes, and so it would introduce the old syntax in the middle of the new. > > If you use a SmaCC-based parser for the new syntax, then you would get along the refactoring engine for that syntax and AST. > > Writing a syntax coloring tool from a Parser is extremely easy, independently of the way this parser is implemented. It can be auto-generated; I did some experiments with Usman on that, and they were very interesting, in particular about the speed of the resulting syntax coloring tool. > >> What do you think ? > > It is a good way to "mold" the browser, in a way. Doru, what do you think? > > Thierry

Aug. 4, 2015

Re: [Pharo-dev] Multiple syntax support in Pharo

by Stephan Eggermont

On 04-08-15 10:08, ClÃ©ment Bera wrote: > Hello Pharoers, > > I'd like to do something a bit crazy and I think it's possible in Pharo > so I'm asking for advises here. > > I would like to have packages / hierarchy of classes in Pharo that have > methods written with a different syntax. I strongly support that. The PostgresV3 integration in Squeak uses that, and I want that for ATDD support (Features, Scenarios, Goals, Stakeholders) Stephan

Aug. 4, 2015

Re: [Pharo-dev] Multiple syntax support in Pharo

by Thierry Goubier

Le 04/08/2015 10:08, ClÃ©ment Bera a Ã©crit : > Hello Pharoers, > > I'd like to do something a bit crazy and I think it's possible in Pharo > so I'm asking for advises here. > > I would like to have packages / hierarchy of classes in Pharo that have > methods written with a different syntax. > > I know that syntax coloring and most refactoring tools work on AST. So > is it possible, for a given class, to override #parser or #parserClass > class side in a similar way that you can override #compiler and > #compilerClass, and from then on, the class methods will use this parser > instead of RBParser to be parse its methods source code to the AST in > the compilation chain and for syntax coloring (hence with full > compatibility with the class browser) ? It depends on how the system browser is implemented, but it sounds doable. I would be able to do that fairly easily on AltBrowser, since commands (all menus and shortcuts, including refactorings) are delegated to the node you are using (i.e. the class, the method, the command) in the browser. Syntax coloring is sort of keyed to the node (i.e. a comment node doesn't do syntax coloring the way a method node does). > I am talking about another syntax that would be parsed to the same AST > for now, though as the compiler can be changed too, I guess a complete > separate compilation chain and AST could work fine if the AST has common > APIs with RB for the refactoring browser and syntax coloring. No, that wouldn't work for refactoring. I believe RB apply refactorings by source code changes, and so it would introduce the old syntax in the middle of the new. If you use a SmaCC-based parser for the new syntax, then you would get along the refactoring engine for that syntax and AST. Writing a syntax coloring tool from a Parser is extremely easy, independently of the way this parser is implemented. It can be auto-generated; I did some experiments with Usman on that, and they were very interesting, in particular about the speed of the resulting syntax coloring tool. > What do you think ? It is a good way to "mold" the browser, in a way. Doru, what do you think? Thierry

Aug. 4, 2015

Re: [Pharo-dev] Multiple syntax support in Pharo

by Jan Vrany

Hi Clement, I have done exactly this a long time ago. I went even further, allowing different methods being written in different languages (so one could have a class with one method in Smalltalk, other in Java, third in JavaScript, fourth in Ruby or even LISP) Now, fiddling with parser/compiler was actually the easiest part. The hard (though not "difficult") part was to make it working so one can commit and load back the package smoothly, senders / implementors work as expected, debugger is not confused, inspector still works and uses the right compiler for the object, changes are written properly and could be actually loaded back. Myriads of little details... And yes, as soon as "the other language" semantics differ from Smalltalk, you expose yourself to a number of interoperability issues, depending how much different it is. Some of these problems are easy, some of them tricky. Most of them tricky :-) So better stick to Smalltalk semantics... And what is the worst :-) even if you manage to make it up and running, then only to find out that "ordinary" programmers don't like it. They want only one language to rule them all. How many times I have heard "I don't like programming in this or that, I want program everything in Smalltalk (substitute for your favorite)". So, be prepared. If you'd still give it a go, I'd be happy to discuss details. My 2 cents. Jan On Tue, 2015-08-04 at 10:08 +0200, ClÃ©ment Bera wrote: > Hello Pharoers, > > I'd like to do something a bit crazy and I think it's possible in > Pharo so I'm asking for advises here. > > I would like to have packages / hierarchy of classes in Pharo that > have methods written with a different syntax. > > I know that syntax coloring and most refactoring tools work on AST. > So is it possible, for a given class, to override #parser or > #parserClass class side in a similar way that you can override > #compiler and #compilerClass, and from then on, the class methods > will use this parser instead of RBParser to be parse its methods > source code to the AST in the compilation chain and for syntax > coloring (hence with full compatibility with the class browser) ? > > I am talking about another syntax that would be parsed to the same > AST for now, though as the compiler can be changed too, I guess a > complete separate compilation chain and AST could work fine if the > AST has common APIs with RB for the refactoring browser and syntax > coloring. > > What do you think ?

Aug. 4, 2015

Re: [Pharo-dev] OSProcess on windows

by Thierry Goubier

Hi Levente, thanks for looking at it :) Le 03/08/2015 23:51, Levente Uzonyi a Ã©crit : > On Mon, 3 Aug 2015, Thierry Goubier wrote: > >> Le 03/08/2015 21:56, David T. Lewis a Ã©crit : >>> The OSProcess implementation for Windows is incomplete. I recommend >>> Levente's ProcessWrapper >>> (http://www.squeaksource.com/ProcessWrapper/) as >>> an alternative for Windows. >> >> And GitFileTree (the main reason for trying to crash the external >> process support on Pharo :) ) uses ProcessWrapper on Windows and >> OSProcess elsewhere. All the reports about the unstability of >> GitFileTree on Windows relate to the combination GitFileTree + >> ProcessWrapper. >> >> Now, if someone knowledgeable with ProcessWrapper wants to check the >> code calling it, I'm all for it :) > > The only code I could find is MCFileTreeGitRepository class's This is the one, yes. > runProcessWrapperGitCommand: aCommandString in: aDirectory > | r | > (Smalltalk at: #ProcessWrapper ifAbsent: [ self error: 'Please load > ProcessWrapper' ]) > ifNotNil: [ :pW | > r := pW new > useStdout; > startWithShellCommand: > self gitCommand , ' -C "' , > (MCFileTreeFileUtils current directoryPathString: aDirectory) , '" ' , > aCommandString; > upToEnd ]. > ^ r > > What is the actual problem with the code? Instability. Git commands fail, and, since GitFileTree uses a few of them, GitFileTree becomes unusable. > Why is the command executed in a shell? Because the OSProcess version was also executing in a shell (and so, by default, the git command had no path). In the current version, the git command has a path and the OSProcess side doesn't use the shell, so it could be the same. Should it be changed for ProcessWrapper as well? Thierry > Levente > >> >> Thierry >> >>> >>> Dave >>> >>> >>>> Thanks for the links. Unfortunately none of these really explain >>>> what the >>>> problem with OSProcess is. I see there were attempts to try using >>>> ProcessWrapper instead of OSProcess on windows, but there's no feedback >>>> on that thread, so there may be a solution out there, but no one is >>>> using >>>> it. >>>> >>>> Levente >>>> >>>> On Mon, 3 Aug 2015, Peter UhnÃÂ¡k wrote: >>>> >>>>> On Mon, Aug 3, 2015 at 7:14 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >>>>> On Mon, 3 Aug 2015, Peter UhnÃÂ¡k wrote: >>>>> >>>>> >>>>> Ã Ã Ã but the git user experience under Windows has >>>>> to be >>>>> improved if we want to use efficiently the other >>>>> functionalities of github (pull requests, commit, >>>>> branches,Ã¢â¬Â¦). >>>>> >>>>> >>>>> Well some of the experience can be mitigated with >>>>> tools like >>>>> GitHub for Windows, but the main problem is that git with >>>>> Pharo is incredibly unstable on Windows and crashes >>>>> constantly. >>>>> That's our experience >>>>> with it so my colleague had to switch to pure filetree >>>>> out >>>>> of frustration. >>>>> This however is NOT problem of git, it's problem of >>>>> OSProcess. But it does render it almost unusable for now. >>>>> (At least for us.) >>>>> >>>>> >>>>> What's the problem with OSProcess on windows? >>>>> >>>>> >>>>> http://forum.world.st/Gitfiletree-unstable-on-Windows-td4816354.html >>>>> http://forum.world.st/gitfiletree-metadata-td4838970.html >>>>> http://forum.world.st/Git-gitfiletree-on-Pharo-vs-Windows-td4806791.html >>>>> >>>>> >>>>> >>> >>> >>> >>> >> >> >>

Aug. 4, 2015

Multiple syntax support in Pharo

by ClÃ©ment Bera

Hello Pharoers, I'd like to do something a bit crazy and I think it's possible in Pharo so I'm asking for advises here. I would like to have packages / hierarchy of classes in Pharo that have methods written with a different syntax. I know that syntax coloring and most refactoring tools work on AST. So is it possible, for a given class, to override #parser or #parserClass class side in a similar way that you can override #compiler and #compilerClass, and from then on, the class methods will use this parser instead of RBParser to be parse its methods source code to the AST in the compilation chain and for syntax coloring (hence with full compatibility with the class browser) ? I am talking about another syntax that would be parsed to the same AST for now, though as the compiler can be changed too, I guess a complete separate compilation chain and AST could work fine if the AST has common APIs with RB for the refactoring browser and syntax coloring. What do you think ?

Aug. 4, 2015

Re: [Pharo-dev] [squeak-dev] The squeaksource.com welcome page needs an update

by Chris Muller

Looks like the hosting message credit is out of date too.. On Mon, Aug 3, 2015 at 5:54 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > The squeaksource.com home page presents a warning that out of date. I > would like to update that message with something more appropriate. The > home page currently says this: > > Note: The creation of new projects has been disabled. If you would like > to create a new project please consider moving to: http://ss3.gemstone.com/ > or http://www.smalltalkhub.com/. > > And it might be better to say something like this: > > Note: If you would like to create a new project please consider using > http://ss3.gemstone.com/. > > Rationale: New project creation is no longer disabled on squeaksource.com. > The smalltalkhub.com site is still beta so I am not sure that it should > be recommended. The ss3.gemstone.com seems to be solid and well supported. > > Does that sound right? Advice is welcome. > > Thanks, > Dave >

Aug. 4, 2015

Re: [Pharo-dev] [squeak-dev] The squeaksource.com welcome page needs an update

by Chris Muller

The first paragraph says, "Welcome to SqueakSource", why should the second paragraph recommend users to go elsewhere? I miss the clean, welcoming, original look of SqueakSource. Does anyone remember why those confusing messages were put there in the first place? PS -- we should ask Pharo if they prefer to have "and Pharo" removed too so it doesn't create confusion for their users if have moved on from Squeaksource. On Mon, Aug 3, 2015 at 5:54 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > The squeaksource.com home page presents a warning that out of date. I > would like to update that message with something more appropriate. The > home page currently says this: > > Note: The creation of new projects has been disabled. If you would like > to create a new project please consider moving to: http://ss3.gemstone.com/ > or http://www.smalltalkhub.com/. > > And it might be better to say something like this: > > Note: If you would like to create a new project please consider using > http://ss3.gemstone.com/. > > Rationale: New project creation is no longer disabled on squeaksource.com. > The smalltalkhub.com site is still beta so I am not sure that it should > be recommended. The ss3.gemstone.com seems to be solid and well supported. > > Does that sound right? Advice is welcome. > > Thanks, > Dave >

Aug. 4, 2015