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

Re: [Pharo-project] Fwd: OverlyComplex

by csrabak＠bol.com.br

Aug. 19, 2009

[Pharo-project] ToolBuilder vs MorphicToolBuilder vs PSToolBuilder

by Eagle Offshore

What are the differences? It looks like most things are just using ToolBuilder right now - correct?

Aug. 19, 2009

Re: [Pharo-project] ORM for Pharo -- Â½ OFF

by Mariano Martinez Peck

Yes, it should. Thanks On 8/18/09, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > > Am 18.08.2009 um 17:23 schrieb Mariano Martinez Peck: > >> >> >> On Tue, Aug 18, 2009 at 10:37 AM, Esteban A. Maringolo >> <emaringolo(a)gmail.com >> > wrote: >> >> This is not the case of Pharo. As you may know, most of the ESUG >> people are under the Pharo project. >> ESUG has selected SqueakDBX as a SummerTalk project and has >> sponsored us, not only in 2008 but again this year. >> See: http://www.esug.org/Promotion/SummerTalk > This page says "Welcome to SummerTalk 2008." Shouldn't it be 2009? > > Andreas

Aug. 19, 2009

Re: [Pharo-project] Fwd: OverlyComplex

by Igor Stasenko

2009/8/19 <csrabak(a)bol.com.br>: > Em 18/08/2009 20:23, Ken.Dickey < Ken.Dickey(a)whidbey.com > escreveu: > >> Igor Stasenko <siguctua(a)gmail.com> >>> Stef, is this an invitation to continue discussion? >> From ISSUE 1072: http://code.google.com/p/pharo/issues/detail?id=1072 >> ============================================== >> >> The intent is that this issue, 1072, introduces some problems which >> motivate >> SLICE-remove-Complex. >> >> I intend to open two new issues to be paired with (unreleased) >> SLICE-basic-Complex and SLICE-extended-Complex. >> >> So I would prefer people to hold back discussions of other issues than >> removal >> of Complex code until I open those issues. >> >> Baby steps. OK? >> ============================================== >> >> So, this is an invitation to the discussion "Should the Complex class and >> associated code be removed from Ph aro-Core?". > > Yes. > >> >> This is NOT an invitation to a discussion of what is reasonable in an >> optional >> Complex package. >> >> ... >>> I don't want to be peevish here, but things like: >>> >>Note that there is no attempt to change oddities of Smalltalk syntax. >>> >>E.g. >>> >>Â (3 + 1/2i) -->Â (0 - 2i)Â NOTÂ (3 + (1/2)i) >>> >>> indicating that Ken don't realizing completely what is Smalltalk. >> > > Well, this comment was not really a inspired one, when I saw it I also had > hitches to post a question to Igor to understand what was the complaint... > Because, to my sense, smalltalk having a few, brilliant concepts, and one of them is uniform syntax rules. If you start adding new rules - it is very likely that you'll make things overly complex & redundant. There are many studies showing that smalltalkers are times more productive than developers who using "industry" programming languages. Do you think they are all genious? Or maybe there is something which increasing their productivity? >> I indicated that I know the Smalltalk syntax by knowing that >> (3 + 1/2i) --> (0 - 2i) >> and indicating I would _not_ change that. >> >> Smalltalk syntax is certainly confusing to people which come from other >> languages which parse 1/2i as a number, which is why I pointed it out -- >> for >> people who don't know the Smalltalk parse strategy. >> > > Also, Etoys already did somenthing about changing the syntax for > mathematical operations http://www.squeakland.org/download/releaseNotes.jsp > >> I presume that you _do_ want users to switch to Smalltalk from other >> languages! Yes? > > Ken, > > Presently the driver for choosing a new platform is not only the language > (here understood as the syntax of it). > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Aug. 19, 2009

Re: [Pharo-project] [squeak-dev] Second LIfe plugin API

by Lawson English

Lawson English wrote: > As part of my on-going work on finding synergy, someone, somewhere, > might want to look at this: > > http://wiki.secondlife.com/wiki/Media_Rendering_Plugin_Framework_Technical_… > > > Apparently the SL plugin test app already handles this: http://www.canvaspaint.org/ So the sky should be the limit for what can be done... Lawson

Aug. 19, 2009

Re: [Pharo-project] Fwd: OverlyComplex

by Igor Stasenko

2009/8/19 Ken.Dickey <Ken.Dickey(a)whidbey.com>: > Igor Stasenko <siguctua(a)gmail.com> >> Stef, is this an invitation to continue discussion? > From ISSUE 1072: Â Â http://code.google.com/p/pharo/issues/detail?id=1072 > ============================================== > > The intent is that this issue, 1072, introduces some problems which motivate > SLICE-remove-Complex. > > I intend to open two new issues to be paired with (unreleased) > SLICE-basic-Complex and SLICE-extended-Complex. > > So I would prefer people to hold back discussions of other issues than removal > of Complex code until I open those issues. > > Baby steps. OK? > ============================================== > > So, this is an invitation to the discussion "Should the Complex class and > associated code be removed from Pharo-Core?". > > This is NOT an invitation to a discussion of what is reasonable in an optional > Complex package. > > ... >> I don't want to be peevish here, but things like: >> >>Note that there is no attempt to change oddities of Smalltalk syntax. >> >>E.g. >> >> Â (3 + 1/2i) --> Â (0 - 2i) Â NOT Â (3 + (1/2)i) >> >> indicating that Ken don't realizing completely what is Smalltalk. > > I indicated that I know the Smalltalk syntax by knowing that > Â (3 + 1/2i) --> Â (0 - 2i) > and indicating I would _not_ change that. > > Smalltalk syntax is certainly confusing to people which come from other > languages which parse 1/2i as a number, which is why I pointed it out -- for > people who don't know the Smalltalk parse strategy. > > I presume that you _do_ want users to switch to Smalltalk from other > languages! Â Yes? > sure i want. I had discovered smalltalk maybe 4 years ago. Before that i knew nothing about smalltalk but already had a programming experience more than a 15 years. But i never, never had a thought to call smalltalk syntax odd. It is most simple & consistent computer language syntax ever designed. I having much more reasons to call a math precedence rules odd, because they are many and you need to learn them and you spending a countless hours in school to learn them. If you remember your childhood - how many pupils (including you) , who had to study math found the math precedence rules odd, confusing and hard to grok them? Compare Roman numeric system with Arabic. Why do you think, a middle-age Europeans and then whole world started using Arabic numeric system instead of Roman? The problem here is with a pattern which sits deep in your brains and preventing you to understand a much more simpler and easy to master concept(s). > -KenD > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Aug. 19, 2009

Re: [Pharo-project] Fwd: OverlyComplex

by csrabak＠bol.com.br

Aug. 19, 2009

Re: [Pharo-project] [croquet-dev] Re: [squeak-dev] Second LIfe plugin API

by Lawson English

https://svn.secondlife.com/svn/linden/branches/2009/plugin-api/indra/media_… Is the source for the plugin samples. That's as much info as I can get past what little is on the wiki... http://wiki.secondlife.com/wiki/Media_Rendering_Plugin_Framework Lawson

Aug. 19, 2009

Re: [Pharo-project] Fwd: OverlyComplex

by Ken.Dickey

Igor Stasenko <siguctua(a)gmail.com> > Stef, is this an invitation to continue discussion? >From ISSUE 1072: http://code.google.com/p/pharo/issues/detail?id=1072 ============================================== The intent is that this issue, 1072, introduces some problems which motivate SLICE-remove-Complex. I intend to open two new issues to be paired with (unreleased) SLICE-basic-Complex and SLICE-extended-Complex. So I would prefer people to hold back discussions of other issues than removal of Complex code until I open those issues. Baby steps. OK? ============================================== So, this is an invitation to the discussion "Should the Complex class and associated code be removed from Pharo-Core?". This is NOT an invitation to a discussion of what is reasonable in an optional Complex package. ... > I don't want to be peevish here, but things like: > >>Note that there is no attempt to change oddities of Smalltalk syntax. > >>E.g. > >> Â (3 + 1/2i) --> Â (0 - 2i) Â NOT Â (3 + (1/2)i) > > indicating that Ken don't realizing completely what is Smalltalk. I indicated that I know the Smalltalk syntax by knowing that (3 + 1/2i) --> (0 - 2i) and indicating I would _not_ change that. Smalltalk syntax is certainly confusing to people which come from other languages which parse 1/2i as a number, which is why I pointed it out -- for people who don't know the Smalltalk parse strategy. I presume that you _do_ want users to switch to Smalltalk from other languages! Yes? -KenD

Aug. 18, 2009

Re: [Pharo-project] Class>>isSystemDefined ?

by Igor Stasenko

2009/8/11 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > Seeing as how isSystemDefined is only false for subclasses of > MorphicModel that ends in a number, I'd say so :) > > Making a version of Etoys which runs on Pharo would be more difficult > to achieve though. > > My 2c: Possibly forcing a rethinking of how to avoid saving auto- > generated classes without hacking it into core methods, can't really > be seen as a bad thing anyways... > Don't ask, tell. (c) instead asking #isSystemDefined, tell class to (or not to) serialize self.. > Cheers, > Henry > > > On Aug 11, 2009, at 4:44 48PM, Alexandre Bergel wrote: > >> Indeed. >> So, is this a good candidate for more cleaning? If yes, I add an entry >> in the wiki and I work on it now. >> >> Alexandre >> >> >> On 11 Aug 2009, at 10:40, Henrik Johansen wrote: >> >>> Sounds a lot to me like something that could be a leftover from >>> Etoys, >>> f.ex. used to support auto-numbered, auto-generated morphs by a user, >>> but avoid saving them to disk etc.Â´... >>> >>> Cheers, >>> Henry >>> >>> On Aug 11, 2009, at 4:04 01PM, Alexandre Bergel wrote: >>> >>>> Dear List members, >>>> >>>> The following method is defined in Class: >>>> -=-=-=-=-=-=-=-=-= >>>> Class>>isSystemDefined >>>> Â Â "Answer true if the receiver is a system-defined class, and not a >>>> UniClass (an instance-specific lightweight class)" >>>> >>>> Â Â ^ self == self officialClass >>>> -=-=-=-=-=-=-=-=-= >>>> >>>> isSystemDefined is sent a number of times. Especially by streams. I >>>> guess that this determines what should be serialized what should >>>> not. >>>> >>>> However, #officialClass has only two implementers: >>>> >>>> -=-=-=-=-=-=-=-=-= >>>> Class>>officialClass >>>> Â Â "I am not a UniClass. Â (See Player officialClass). Â Return the >>>> class >>>> you use to make new subclasses." >>>> >>>> Â Â ^ self >>>> -=-=-=-=-=-=-=-=-= >>>> >>>> And slightly more surprising: >>>> >>>> -=-=-=-=-=-=-=-=-= >>>> MorphicModel>>officialClass >>>> Â Â "We want to make a new instance of the receiver, which is a >>>> subclass >>>> of MorphicModel. Â Answer who to make a new subclass of. Â Also used >>>> to >>>> tell if a given class is a UniClass, existing only for its single >>>> instance." >>>> >>>> Â Â ^ self name last isDigit ifTrue: [MorphicModel] ifFalse: [self] >>>> Â Â Â Â Â Â "MorphicModel7 can not have subclasses, but Slider and >>>> SystemWindow >>>> may" >>>> -=-=-=-=-=-=-=-=-= >>>> >>>> There is a very strong smell for cleaning here. Apparently, most of >>>> usage of #isSystemDefined could be replaced by #isBehavior >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel Â http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel Â http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Aug. 18, 2009