- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] still getting vm bug...

by Esteban A. Maringolo

Side question: Which debugger is that? Me-likes-it. :)

Aug. 28, 2014

Re: [Pharo-dev] Roadmap on tools?

by kmo

philippeback wrote > Building a UI with Morphic alone is what one would use to do something > very > custom (like a game for example). > > Now, creating a larger UI that way is definitely going to be super pain in > the assets. > > That's where Spec does fit. Is there any evidence of this? As far as I know no one has built anything more complex than a class browser. I would say Spec was incapable of building a complex interface of any kind. It's clumsy, developer-hostile, and counter-intuitive. The whole Spec process of writing code in three different places is the very definition of a /super pain in the asset/s. it is far less intuitive to my mind than creating composite morphs. Progress on Spec is glacially slow - but that's not the problem. Spec is profoundly misconceived and fundamentally flawed and offers nothing over raw Morphic. The Spec model is simply not how anyone would want to build an interface in 2014. I certainly would never use it. -- View this message in context: http://forum.world.st/Roadmap-on-tools-tp4774285p4775282.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 28, 2014

[pharo-project/pharo-core]

by GitHub

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

Aug. 28, 2014

[pharo-project/pharo-core] 765f14: 40194

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 765f149f77d08ea24f50c5c45e579d4cee435f57 https://github.com/pharo-project/pharo-core/commit/765f149f77d08ea24f50c5c4… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-28 (Thu, 28 Aug 2014) Changed paths: M OpalCompiler-Core.package/AbstractCompiler.class/class/settings/compilerSettingsOn_.st A OpalCompiler-Core.package/CCompilationContext.class/class/accessing/allowBlockArgumentAssignment.st A OpalCompiler-Core.package/CCompilationContext.class/class/accessing/allowBlockArgumentAssignment_.st M OpalCompiler-Core.package/CCompilationContext.class/definition.st A OpalCompiler-Core.package/CCompilationContext.class/instance/accessing/allowBlockArgumentAssignment.st A OpalCompiler-Core.package/CompilationContext.class/class/accessing/allowBlockArgumentAssignment.st A OpalCompiler-Core.package/CompilationContext.class/class/accessing/allowBlockArgumentAssignment_.st M OpalCompiler-Core.package/CompilationContext.class/definition.st A OpalCompiler-Core.package/CompilationContext.class/instance/accessing/allowBlockArgumentAssignment.st A OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/variables/checkVariableIsWritable_.st M OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/variables/lookupVariableForWrite_.st R OpalCompiler-Core.package/OCAbstractMethodScope.class/instance/testing/isBlockScope.st R OpalCompiler-Core.package/OCAbstractMethodScope.class/instance/testing/isMethodScope.st A OpalCompiler-Core.package/OCAbstractScope.class/instance/testing/isBlockScope.st A OpalCompiler-Core.package/OCAbstractScope.class/instance/testing/isMethodScope.st A OpalCompiler-Core.package/OCAbstractVariable.class/instance/testing/isWritable.st A OpalCompiler-Core.package/OCSpecialVariable.class/instance/testing/isWritable.st A OpalCompiler-Core.package/OCTempVariable.class/instance/testing/isWritable.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script194.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40194.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40194 13897 check for argument assignments (block and method argumentts) https://pharo.fogbugz.com/f/cases/13897 http://files.pharo.org/image/40/40194.zip

Aug. 28, 2014

Re: [Pharo-dev] Opal, custom compilers and class-side methods

by Marcus Denker

On 28 Aug 2014, at 16:32, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 28 Aug 2014, at 16:03, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> >> On 28 aoÃ»t 2014, at 15:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>>> >>>> On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel(a)gmail.com> wrote: >>>> >>>>> Hi all, >>>>> >>>>> With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side: >>>>> MyClass class>>#compilerClass >>>>> ^ MySpecialCompiler >>>>> >>>> >>>> Iâve missed this feature. This is super cool! >>>> >>> >>> There is now in addition #compiler, an instance, not the class. >> >> Hum right... I should do the same thing with a #classSideCompiler then, right? >> > yesâ¦ but when #compiler is set, it should be valid for both instance and class side... or not: as it seems to never have applied to the class side, it should be fine to keep them separate. that is, #compiler applies to instance side, and a classSideCompiler applies to the class side by default people only override the instance side one, but when needed, they can override the classSide one, too. (e.g. when you do a DSL, you want to still have the #initialize on the class side be untouched smalltalk in most cases). Marcus

Aug. 28, 2014

Re: [Pharo-dev] Opal, custom compilers and class-side methods

by Marcus Denker

On 28 Aug 2014, at 16:03, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 28 aoÃ»t 2014, at 15:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >>> >>> On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel(a)gmail.com> wrote: >>> >>>> Hi all, >>>> >>>> With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side: >>>> MyClass class>>#compilerClass >>>> ^ MySpecialCompiler >>>> >>> >>> Iâve missed this feature. This is super cool! >>> >> >> There is now in addition #compiler, an instance, not the class. > > Hum right... I should do the same thing with a #classSideCompiler then, right? > yesâ¦ but when #compiler is set, it should be valid for both instance and class side... >> >> This is useful as you can set compiler options this way. e.g. InstructionStream does not need to use a subclass but can do >> >> compiler >> "The JIT compiler needs to trap all reads to instance variables of contexts. As this check is costly, it is only done >> in the long form of the bytecodes, which are not used often. In this hierarchy we force the compiler to always generate >> long bytecodes" >> ^super compiler options: #(+ optionLongIvarAccessBytecodes) >> >

Aug. 28, 2014

Re: [Pharo-dev] Opal, custom compilers and class-side methods

by Igor Stasenko

On 28 August 2014 15:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > Hi all, > > With Opal, if you want to customize how methods are compiled into a class > you can override #compilerClass on class-side: > MyClass class>>#compilerClass > ^ MySpecialCompiler > > > Iâve missed this feature. This is super cool! > > > There is now in addition #compiler, an instance, not the class. > > Right. Factory method(s) like this are significantly more flexible, since implementor may want to provide a special way of initializing the compiler, you can't foresee via class standard '#new' protocol before hanging it over to user. Giving just a class, make things quite hard and limiting.. especially in situation when developer wants to make a subclass which carries additional state , which needs to be initialized properly. That's why, I prefer to use factory methods instead of 'SomethingClass' everywhere i need. > This is useful as you can set compiler options this way. e.g. > InstructionStream does not need to use a subclass but can do > > compiler > "The JIT compiler needs to trap all reads to instance variables of > contexts. As this check is costly, it is only done > in the long form of the bytecodes, which are not used often. In this > hierarchy we force the compiler to always generate > long bytecodes" > ^super compiler options: #(+ optionLongIvarAccessBytecodes) > > -- Best regards, Igor Stasenko.

Aug. 28, 2014

Re: [Pharo-dev] PharoLauncher on Windows not the latest version

by Tim Mackinnon

Kilon - it would be good if we could percevear to try and get a fix and detailed instructions for other less confident usersâ¦ At least test Benâs updated installer so we can clear this. I appreciate the aggravation you are putting up with. Tim On 28 Aug 2014, at 10:35, kilon alios <kilon.alios(a)gmail.com> wrote: > My work pc is dual boot to ubuntu and win 7 . I am not a fan of linux either, loads of problems there but nowhere near as bad as windoom. > > I need windoom because of a Greek OCR I use at work to scan legal documents. I have no choice other than to continue using it. > > I dont care what the corporate world does or the fact that almost 100% of my fellow lawyers use windoom and some still DOS. Thats their problem :D > > It would be nice to support what 95% of people use out there, but alas I cant take it anymore. Coding should be fun, Windoom kills my inner child. Sorry for those that have to tolerate this crap, but I am lucky enough not to . > > /ranting off > > > On Thu, Aug 28, 2014 at 11:50 AM, Ben Coman <btc(a)openinworld.com> wrote: > kilon alios wrote: > ok thing get worse and worse > > I try to run pharo as administrator and pharo opens and exits immediately , it creates a stderr which contains the following > > http://pastebin.com/v9Hpx9pK > > I found the folder you mentioned and I deleted it , now pharo does not open at all even when run without "run as administrator" > Boy I hate Windoom. I also tried Tim link , nothing, pharo opens but does nothing, no gui, nothing. I know it opens because i can see its process in the task manager which i have to terminate manually. > I do all my coding and art on macos, I only have windows at work so i can test my code on windoom too, but this was the last straw, I had enough with this uber crappy OS for 17 years now. I am dropping support for it and sticking to MacOS only. > Thanks guys for your help but it does not worth it. I hope no other windows user experience my problem. > > > I empathize. I've been a Linux advocate for years, but never made the full desktop switch since I needed a Windows system for corporate compatibility. Then I got a mac-mini to experiment with iPad Mobile Device Management, and found it easier to get Latex working on it than on Windows (for processing Pillar output), and now I find myself using it for Pharo more every day, and my Windows box is starting to be neglected (except I still need to migrate my old Thunderbird email archive). > > However success in the corporate world still hinges a lot on Windows compatibility. I will still have a go at updating PharoLauncher Installer to avoid this problem. > cheers, Ben > > P.S. @Tim, Your alternate-VM feature sound interesting. I'll check it out. > >

Aug. 28, 2014

Re: [Pharo-dev] Opal, custom compilers and class-side methods

by Camille Teruel

On 28 aoÃ»t 2014, at 15:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 28 Aug 2014, at 15:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> >> On 27 Aug 2014, at 17:53, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >>> Hi all, >>> >>> With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side: >>> MyClass class>>#compilerClass >>> ^ MySpecialCompiler >>> >> >> Iâve missed this feature. This is super cool! >> > > There is now in addition #compiler, an instance, not the class. Hum right... I should do the same thing with a #classSideCompiler then, right? > > This is useful as you can set compiler options this way. e.g. InstructionStream does not need to use a subclass but can do > > compiler > "The JIT compiler needs to trap all reads to instance variables of contexts. As this check is costly, it is only done > in the long form of the bytecodes, which are not used often. In this hierarchy we force the compiler to always generate > long bytecodes" > ^super compiler options: #(+ optionLongIvarAccessBytecodes) >

Aug. 28, 2014

Re: [Pharo-dev] Check multiple boxes in TreeModel

by Yuriy Tymchuk

`autoMultiSelection: true` does the job Does anybody know what #removeOnlyLastSelected: is for? Because itâs also used by Komitterâ¦ Uko On 28 Aug 2014, at 15:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Iâll take a look. > > Thanks Christophe! > > On 28 Aug 2014, at 15:37, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > >> >> Le 28 aoÃ»t 2014 Ã 15:31, Yuriy Tymchuk a Ã©crit : >> >>> HI guys, >>> >>> is it possible? Iâve tried `autoDeselection: false`, `multiSelection: true`â¦ and it continues to deselect selected items :(. Maybe there is any kind of example how to do a classic checkbox tree? For example if we have filesystem and want to select which items to backup. >> >> I did not check the code but at least Komitter do the thing you want to do. >> It should be easy to trigger out the way to configure your treeModel from there. >> >> Christophe >> > >

Aug. 28, 2014