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

Re: [Pharo-dev] Glorp Login>>#encodingStrategy

by Sven Van Caekenberghe

On 27 Aug 2014, at 18:20, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-08-27 12:38 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> It seems that Glorp Login>>#encodingStrategy is not used by the NativePostgresDriver yet it is required to set it to a non nil value to get things working. This feels like a hack or something unfinished. > > How so? > > PGConnection>>#clientEncoding: sets instance variables > sqlStringConverter and receivingTextConverter, which are used to > convert text back and forth from Pharo to the socket (see > PGConnection>>#execute:) > > It is really convoluted, but I guess this has to do with the pass of > time, and also with the half-backed (IMO) driver independence and > dialect compatibility. > > Regards! > > Esteban A. Maringolo Thanks for your answer. I was confused by the name change between encodingStrategy and clientEncoding. You are right it is used. But my point remains that unless you set encodingStrategy on Login to something you get an error when nil in converted to a Symbol (in #connectionArgsFromCurrentLogin:). Now, I set it to #default which does not exist as encoding and leads to no encoding at all. That seems to indicate that it is not needed, but I am not sure. Sven The before last line of #connectionArgsFromCurrentLogin: could be changed to aLogin encodingStrategy ifNotNil: [ :enc | connectionArgs clientEncoding: enc asSymbol ].

Aug. 28, 2014

Re: [Pharo-dev] Roadmap on tools?

by Esteban A. Maringolo

2014-08-28 16:32 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: > > Le 28 aoÃ»t 2014 20:16, "kmo" <voxkmp(a)gmail.com> a Ã©crit : > > >> >> philippeback wrote > UI work is hard to do well with scarce resources. > > At the end of the day, my UIs are done in HTML5, JQuery and CSS + SVG. As the UIs of most of the solutions out there. Sneaking into smartphones, kiosks, cars... and other IDEs as well. :) Esteban A. Maringolo

Aug. 28, 2014

Re: [Pharo-dev] Future of Spec

by kilon alios

Well as the discussion was in another thread , Spec is licensed as MIT inside Pharo , the new GPL license seems to affect any present and future contributions from Ben. So I will say yes it looks like Spec is here to stay, I may not be a fan of Spec design but they are many Pharoers out there that they are and since Pharo community is quite democratic looks like Spec is here to stay. The Pharo team wont be able to add in Pharo any GPL affected contributions of Ben ( assuming Ben continuous to develop Spec which I doubt) but Pharoers can continue to contribute to the Pharo MIT Spec . So it looks like the effect is minimum if you exclude the fact we lost the most major contributor to Spec. So far the idea is to push forward both Spec and Morphic and personally I really like this idea as it lets people more options on the GUI front which can be only good thing since anyone this way can use the right tool for his or her own needs. It would also be a lot of shame if Ben's hard work goes to waste even though he decided to give up pharo, we have to respect his choice but also his work make sure his effort don't go wasted as he built a tool that many people find useful. So yes you can keep using Spec and I am sure we will all appreciate any contribution you make to Spec :) On Thu, Aug 28, 2014 at 10:15 PM, Martin Saurer <martin.saurer(a)bluewin.ch> wrote: > Dear all, > > A few weeks ago, I read about the dispute on Spec, which has escalated, > and as a result of that, Ben has left the Pharo/Smalltalk community. It's > always sad when a long term member leaves, but live is going on. > > From my (somewhat business minded) point of view one question is currently > unanswered: > Is there a future of Spec (without Ben)? > > I'm asking this because I'm the author of a web frontend engine which can > be bound to a programming language (like Pharo) to create desktop-like web > applications. Currently there is an implementation for the J programming > language as well as a rough (but working) implementation for Pharo. My > plans for the (far) future is to bind the frontend engine to Pharo in a > more elegant way probably by extending Spec. So one may write a desktop > application in Spec, and a corresponding web GUI is automatically created > as well. > > So I'm currently a little unsure whether to go with Spec or going back to > the good old Polymorph. > > Is somebody of the core team able to clarify the situation? > > Many thanks in advance. > > Martin > > > >

Aug. 28, 2014

Re: [Pharo-dev] Roadmap on tools?

by phil＠highoctane.be

Le 28 aoÃ»t 2014 20:16, "kmo" <voxkmp(a)gmail.com> a Ã©crit : > > 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. > What it offers is some regularity over the API Frankly, do you find that the Morphic widgets APIs are ok? On Java I used Swing a lot. But that was no walk in the park either. Even with tools like Matisse. In Tcl/Tk things were good but all by hand. And the widgets were aged despite some efforts. UI work is hard to do well with scarce resources. At the end of the day, my UIs are done in HTML5, JQuery and CSS + SVG. And clients are fine with that. Maybe with SDL and Woden will we get something new. Phil > > > > > > > -- > 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

Future of Spec

by Martin Saurer

Dear all, A few weeks ago, I read about the dispute on Spec, which has escalated, and as a result of that, Ben has left the Pharo/Smalltalk community. It's always sad when a long term member leaves, but live is going on. >From my (somewhat business minded) point of view one question is currently unanswered: Is there a future of Spec (without Ben)? I'm asking this because I'm the author of a web frontend engine which can be bound to a programming language (like Pharo) to create desktop-like web applications. Currently there is an implementation for the J programming language as well as a rough (but working) implementation for Pharo. My plans for the (far) future is to bind the frontend engine to Pharo in a more elegant way probably by extending Spec. So one may write a desktop application in Spec, and a corresponding web GUI is automatically created as well. So I'm currently a little unsure whether to go with Spec or going back to the good old Polymorph. Is somebody of the core team able to clarify the situation? Many thanks in advance. Martin

Aug. 28, 2014

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

by Max Leske

On 28.08.2014, at 20:59, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Side question: Which debugger is that? Me-likes-it. :) Thatâs the GT debugger. Itâs part of the Glamourous Toolkit developed with Moose (moosetechnology.org) You should checkout the material on GTInspector from ESUG by Tudor Girba and Andre Chis (e.g. here https://www.youtube.com/watch?v=fa9Zpxyt_no&index=36&list=PLJ5nSnWzQXi_6yyR…) Cheers, Max

Aug. 28, 2014

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