- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] line endings

by stepharo

Le 4/8/15 12:09, Sven Van Caekenberghe a Ã©crit : > We should indeed consider doing it, I believe Cuis has done the same. yes But we should finish all the change we started :) > >> 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] Google Code Shutdown

by Tudor Girba

No, you did not miss anything. I think there was a misunderstanding :). The GitHub repo is for entries only. But, we could try to mirror the SmalltalkHub repo into GitHub. I do not know how to do that, but if someone would like to do it, it would be great. Doru On Tue, Aug 4, 2015 at 9:20 PM, stepharo <stepharo(a)free.fr> wrote: > Why would it be a problem to manage just bug entries? > Did I miss something? > Stef > > > Le 3/8/15 11:56, Peter UhnÃ¡k a Ã©crit : > > As long as nobody on your team is using Windows, git(hub) is quite good. > :) > (And if you have Windows user, then find him a therapy first, or push for > libcgit :)) > > On Mon, Aug 3, 2015 at 4:35 AM, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > >> Github is indeed appealing. >> >> Cheers, >> Alexandre >> >> >> >> > On Aug 2, 2015, at 10:14 PM, Sean P. DeNigris <sean(a)clipperadams.com> >> wrote: >> > >> > Tudor Girba-2 wrote >> >> Would you like to help us move the moose-technology project? >> > >> > Sure. What do you have in mind? It seems exporting to GitHub is the >> easiest >> > option. There are a few limitations, but I've had good experiences... >> > >> > >> > >> > ----- >> > Cheers, >> > Sean >> > -- >> > View this message in context: >> http://forum.world.st/Google-Code-Shutdown-tp4814760p4840733.html >> > Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> > >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 4, 2015

Re: [Pharo-dev] Google Code Shutdown

by stepharo

Why would it be a problem to manage just bug entries? Did I miss something? Stef Le 3/8/15 11:56, Peter UhnÃ¡k a Ã©crit : > As long as nobody on your team is using Windows, git(hub) is quite > good. :) > (And if you have Windows user, then find him a therapy first, or push > for libcgit :)) > > On Mon, Aug 3, 2015 at 4:35 AM, Alexandre Bergel > <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > > Github is indeed appealing. > > Cheers, > Alexandre > > > > > On Aug 2, 2015, at 10:14 PM, Sean P. DeNigris > <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: > > > > Tudor Girba-2 wrote > >> Would you like to help us move the moose-technology project? > > > > Sure. What do you have in mind? It seems exporting to GitHub is > the easiest > > option. There are a few limitations, but I've had good > experiences... > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Google-Code-Shutdown-tp4814760p4840733.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Aug. 4, 2015

Re: [Pharo-dev] why do I get a slice when I just want to commit package with versioner?

by stepharo

Thanks. I was not awre of this "feature" Stef Le 2/8/15 01:06, Sean P. DeNigris a Ã©crit : > stepharo wrote >> (there is only slice in the combo box choice). > IIRC this happens when Versionner can't find a repository common to all > packages. I guess it's a result of Komitter being used outside its > originally intended context... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/why-do-I-get-a-slice-when-I-just-want-to-commit-packa… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Aug. 4, 2015

Re: [Pharo-dev] Is Metacello in Pharo 5.0 up-to-date? and project locking

by stepharo

> Hi, > > You can find a recent version of Metacello on the latest Pharo 5.0 image there: https://ci.inria.fr/rmod/job/Metacello-CDrepo > I already have a pull request opened for that: https://github.com/dalehenrich/metacello-work/pull/351 So does it mean that we have now the latest version within Pharo 50? Stef > > Christophe > > > Le 24 juil. 2015 Ã 11:48, Marcus Denker a Ã©crit : > >>> On 24 Jul 2015, at 11:14, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>> >>> Hi Peter, >>> >>> the FileTree part is solved, as far as I could do (i.e. all tests green with Pharo5 on Linux), but there is a failure in the travis CI of the most annoying type: the filetree code isn't even loaded :( >>> >>> I'm going on annual leave later today, and Dale told me he won't be easily available for a few weeks; I'll try to make some progress on it during the holidays, but don't count too much on it ;) >>> >>> In the meantime, if someone would be nice to setup Metacello and FileTree in Pharo5 as external projects with a configuration, it would immensely help. >> Yes, that would be nice! Sadly I have no time to do this until my holidaysâ¦ >> >> issue tracker entry is here: >> https://pharo.fogbugz.com/f/cases/15456/Load-latest-version-of-metacello >> >> Marcus

Aug. 4, 2015

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

by serge.stinckwich＠gmail.com

I start to work to resurrect Helvetia some months ago by starting with QuasiQuote: http://smalltalkhub.com/#!/~SergeStinckwich/Helvetia/ but I was distracted by other tasks. I'm still interested to made progress here. I will have a look when I came back from my hollidays. Sent from my iPhone > On 4 aoÃ»t 2015, at 17:01, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Indeed, Helvetia did this and little more. For example: > - it provided a way to combine multiple syntaxes within the same method > - it provided complete debugging with stepping and proper highlighting > > The only reason this was not productized more thoroughly at the time is that we did not have Opal. But, as we have it now, it would be really cool to have Helvetia resurrected. Especially now that, as Thierry said, we also start to have moldable tools so the tooling part becomes easier, too. > > @Clement: would you like to look at Helvetia and explore how feasible it is to resurrect it? > > Cheers, > Doru > > > > > >> On Tue, Aug 4, 2015 at 11:09 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Hi, >> >> AFAIK, this was Lukas phd thesis: 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 > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Aug. 4, 2015

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

by Eliot Miranda

On Mon, Aug 3, 2015 at 3: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. > Looks sensible to me. But I'd really like that front page to explain who "We" is. Also, the code is the most important thing. Is there a backup of the packages? We need to make sure there is a reliable backup of all that code. _,,,^..^,,,_ best, Eliot

Aug. 4, 2015

Re: [Pharo-dev] OSProcess on windows

by Thierry Goubier

Le 04/08/2015 19:13, Levente Uzonyi a Ã©crit : > On Tue, 4 Aug 2015, Thierry Goubier wrote: > >> 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. > > What does "fail" mean here? > Do you have a reproducible case? I don't have anything there because I don't use Windows. I wrote the windows support the best I could without running it, hoping for a microsoft user to confirm it would work :( > Have you tried enabling logging to see what happens when the error > occurs? (You can do it by evaluating [ProcessWrapper logLevelDebug]. > This will create a log file named ProcessWrapper.log, and log the > activities of the plugin there.) Good to know. >> >>> 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? > > If git doesn't have to be run from a shell on windows, then it's > probably better to not use a shell. Ok, I'll change that as soon as I reach a better situation to do some coding. Thierry > Levente > >> >> 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

Re: [Pharo-dev] OSProcess on windows

by Levente Uzonyi

On Tue, 4 Aug 2015, Thierry Goubier wrote: > 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. What does "fail" mean here? Do you have a reproducible case? Have you tried enabling logging to see what happens when the error occurs? (You can do it by evaluating [ProcessWrapper logLevelDebug]. This will create a log file named ProcessWrapper.log, and log the activities of the plugin there.) > >> 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? If git doesn't have to be run from a shell on windows, then it's probably better to not use a shell. Levente > > 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

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

by Tudor Girba

Indeed, Helvetia did this and little more. For example: - it provided a way to combine multiple syntaxes within the same method - it provided complete debugging with stepping and proper highlighting The only reason this was not productized more thoroughly at the time is that we did not have Opal. But, as we have it now, it would be really cool to have Helvetia resurrected. Especially now that, as Thierry said, we also start to have moldable tools so the tooling part becomes easier, too. @Clement: would you like to look at Helvetia and explore how feasible it is to resurrect it? Cheers, Doru On Tue, Aug 4, 2015 at 11:09 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > AFAIK, this was Lukas phd thesis: 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 > > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 4, 2015