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

Re: [Pharo-dev] [Cuis-dev] [Ann] Cuis is now Spur enabled!

by David T. Lewis

On Fri, Aug 19, 2016 at 12:23:51PM -0300, Juan Vuletich via Cuis-dev wrote: > Hi Folks, > > I've successfully finished the Spur conversion of Cuis. I was able to > merge all required changes to Cuis compiler and make it work in both > ObjectMemories. Cuis is now offered in Spur and pre-Spur formats. And > the best part is that they share 100% of the source code. There is no > forking! > Congratulations Juan and Eliot, this is very impressive! Dave

Aug. 19, 2016

Re: [Pharo-dev] <example>/<examplar>

by Sean P. DeNigris

stepharo wrote > Let me know. I do not care about examplar or sample. In the original thread [1]: - The most popular naming option was for some combination of exampleInstance, exampleCode, sampleInstance, and sampleCode because they are both natural-sounding-to-native-ears and explicit. - There was a small (Ben and I) consensus leaning specifically toward <exampleCode> together with <sampleInstance> - Exemplar (note it's not spelled exAmplar) is a bit obscure English - There were some more exotic parameterized varieties discussed, but maybe it's best to save those for a future evolution [1] http://forum.world.st/lt-example-gt-pragmas-and-example-methods-use-cases-t… ----- Cheers, Sean -- View this message in context: http://forum.world.st/example-examplar-tp4911728p4911947.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 19, 2016

Re: [Pharo-dev] Epicea import+revert instead of redo+undo changes? (Was: Re: [pharo-project/pharo-core] f57843: 60163)

by Martin Dias

On Fri, Aug 19, 2016 at 12:14 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Esteban A. Maringolo wrote > >> I think âapplyâ is better. âimportâ sounds too specific to me. I donât > >> want > >> to care where the entries come from and âimportâ implies that there may > >> be > >> something else going on (also: if thereâs an import whereâs the > export?). > > +1. Apply/revert sound right to me also. > Good! thanks; next release will have apply / revert Martin

Aug. 19, 2016

[Ann] Cuis now runs on Spur!

by juanlists＠jvuletich.org

Hi Folks, I've successfully finished the Spur conversion of Cuis. I was able to merge all required changes to Cuis compiler and make it work in both ObjectMemories. Cuis is now offered in Spur and pre-Spur formats. And the best part is that they share 100% of the source code. There is no forking! This means that there is no extra work in maintaining both flavors. So, we are not leaving anyone behind. It also means that, at deployment, you might chose between better performance and larger memory (with Spur) or smaller footprint and SqueakJS compatibility (with pre-Spur). I've just updated our GitHub repo https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev . Included are Cuis4.2-2906-spur.image and Cuis4.2-2906.image, and, as usual, the whole update stream. I wrote a brief description of the Spur conversion at Documentation/SpurConversion.md, in case you want to reproduce it, or apply it to your own Cuis images. The images seem very stable. Please test them, load your code, and report any issues. This work was enabled by Eliot Miranda and the OpenSmalltalk team who develop Spur, VMMaker and the Spur bootstrap. Thank you folks! I also used Squeak 5 as a reference implementation of Compiler and related stuff. I also want to thank the greater Squeak community for it. Some cleanup is in order. The scaffolding I did for the conversion, including dual Compilers is still in the image. I'll be cleaning it soon. I'll also be able to pay a bit more attention to unrelated suggestions and ongoing discussion at cuis-dev(a)cuis-smalltalk.org Enjoy! Cheers, Juan Vuletich www.cuis-smalltalk.org https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev @JuanVuletich

Aug. 19, 2016

Re: [Pharo-dev] Epicea import+revert instead of redo+undo changes? (Was: Re: [pharo-project/pharo-core] f57843: 60163)

by Sean P. DeNigris

Esteban A. Maringolo wrote >> I think âapplyâ is better. âimportâ sounds too specific to me. I donât >> want >> to care where the entries come from and âimportâ implies that there may >> be >> something else going on (also: if thereâs an import whereâs the export?). +1. Apply/revert sound right to me also. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Epicea-import-revert-instead-of-redo-undo-changes-Was… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 19, 2016

Re: [Pharo-dev] Epicea import+revert instead of redo+undo changes? (Was: Re: [pharo-project/pharo-core] f57843: 60163)

by Esteban A. Maringolo

2016-08-19 5:47 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 19 Aug 2016, at 10:43, Max Leske <maxleske(a)gmail.com> wrote: > > I think âapplyâ is better. âimportâ sounds too specific to me. I donât want > to care where the entries come from and âimportâ implies that there may be > something else going on (also: if thereâs an import whereâs the export?). > +1 :) +1 here I was thinking about apply/revert as well. If you use git-cherry-pick its description says: "Apply the changes introduced by some existing commits" I prefer it. Esteban A. Maringolo

Aug. 19, 2016

Re: [Pharo-dev] STON and (default) line endings

by Peter Uhnak

On Fri, Aug 19, 2016 at 02:55:08PM +0200, Sven Van Caekenberghe wrote: > Yes it would make much more sense to default to LF EOL (maybe not on Windows) in this century, but that is true for the whole image ... I agree, but this is imho very simple and actionable change and a step forward. Changing whole image is a much bigger issue. Re Windows: we should make a poll among Windows users to see what makes the most sense for them. Peter > > > On 19 Aug 2016, at 14:49, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > can we have a class-side configuration for STON line ending? > > > > Atm if I want to output with LF instead of CR (which is always), > > then I have to always do this > > > > String streamContents: [ :stream | > > (STON writer on: stream) > > prettyPrint: true; > > newLine: String lf; > > nextPut: data > > ]. > > > > I would be much happier if at least I could do this > > > > STON lineEnding: String lf > > > > (I could put the above in a StartupScript) > > > > And then just use regular STON toStringPretty: data. > > > > > > And I would be even happier if > > > > STON class>>lineEnding > > ^ String lf > > > > or > > > > STON class>>lineEnding > > ^ OSPlatform current isWindows > > ifTrue: [ String crlf ] > > ifFalse: [ String lf ] > > > > (Although always using LF by default might be preferable.) > > > > To summarize, it would be great if we could: > > > > * switch STON to LF _by default_ > > * allow users to easily switch to CR/CRLF if they need > > > > Thanks, > > Peter > > > >

Aug. 19, 2016

Re: [Pharo-dev] STON and (default) line endings

by Sven Van Caekenberghe

Yes it would make much more sense to default to LF EOL (maybe not on Windows) in this century, but that is true for the whole image ... > On 19 Aug 2016, at 14:49, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi, > > can we have a class-side configuration for STON line ending? > > Atm if I want to output with LF instead of CR (which is always), > then I have to always do this > > String streamContents: [ :stream | > (STON writer on: stream) > prettyPrint: true; > newLine: String lf; > nextPut: data > ]. > > I would be much happier if at least I could do this > > STON lineEnding: String lf > > (I could put the above in a StartupScript) > > And then just use regular STON toStringPretty: data. > > > And I would be even happier if > > STON class>>lineEnding > ^ String lf > > or > > STON class>>lineEnding > ^ OSPlatform current isWindows > ifTrue: [ String crlf ] > ifFalse: [ String lf ] > > (Although always using LF by default might be preferable.) > > To summarize, it would be great if we could: > > * switch STON to LF _by default_ > * allow users to easily switch to CR/CRLF if they need > > Thanks, > Peter >

Aug. 19, 2016

Re: [Pharo-dev] Usability issue : the class/instance button in Pharo 5 gives poor feedback

by Peter Uhnak

On Fri, Aug 19, 2016 at 02:15:06PM +0200, Oscar Nierstrasz wrote: > > Hi Folks, > > Does anyone else find this to be a problem? I can never tell whether I am on the class or the instance side as the button toggle is non-obvious. In fact, the (C) is more clearly visible on the instance side, which is counter intuitive. > > I would rather see the name of the button change between âInstanceâ and âClassâ so I always know where I am. This would be imho confusing, because you would always see the opposite (it's a button, so the label should state what should happen when you click on it, not describing the current context). But there is also another visual clue which always makes it obvious (for me at least) on which side I am: on class side all methods are bold. Peter

Aug. 19, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60188 Home: https://github.com/pharo-project/pharo-core

Aug. 19, 2016