- Pharo-dev - lists.pharo.org

[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

[pharo-project/pharo-core] 5dfcea: 60188

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 5dfcea3320fb3b8942a80337b07de7565f30e73c https://github.com/pharo-project/pharo-core/commit/5dfcea3320fb3b8942a80337… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-19 (Fri, 19 Aug 2016) Changed paths: M Kernel.package/MessageSend.class/instance/evaluating/value.st M Kernel.package/MessageSend.class/instance/evaluating/value_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60187.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60188.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60187.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60188.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60188 18158 MessageSend should not care about obsolete classes https://pharo.fogbugz.com/f/cases/18158 http://files.pharo.org/image/60/60188.zip

Aug. 19, 2016

STON and (default) line endings

by Peter Uhnak

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 Sven Van Caekenberghe

Oscar, > On 19 Aug 2016, at 14:15, Oscar Nierstrasz <oscar.nierstrasz(a)gmail.com> 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. > > Cheers, > Oscar You are right, toggle buttons are never very intuitive. Two way switches with double green/gray labels are better but take more space. In Pharo 6 Dark Theme, there are several 'clear' differences: the blue of the class button selection (pressed), the title of the browser window, the changed template or protocols, no ? It is not perfect, but good enough, there is no easy improvement without taking more space, IMHO. Sven

Aug. 19, 2016