September 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Naming of Global Session

by Goubier Thierry

It seems that Pharo 3.0 had a tendency to switch to abstract names instead for that sort of concept... 2.0 OSPlatform platformName -> 3.0 Smalltalk os name 2.0 vmVersion -> 3.0 Smalltalk vm version To keep with that, I'd say that Session isn't to be used directly, but we can access it via: Smalltalk vm session or Smalltalk session (and, if we can access the external user session, we may also use "tentatively" Smalltalk os session!). It can then stay as Session, ImageSession or whatever. Thierry Le 12/09/2013 13:11, Torsten Bergmann a Ã©crit : > In Pharo 3.0 there is a new class "Session" - to represent the current smalltalk > session. Using the term "Session" is very abstract. > > IMHO I would rather like to see it named more specific like "ImageSession", > "PharoSession" or "SmalltalkSession" before it get used too much. > > Any comments? > T. > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 12, 2013

Re: [Pharo-dev] Workspace Moprh Bug with image 30389

by Fernando Olivero

Sure! It was my original intent for the design, thanks for pointing that out. The 11586 issue includes the fix and refactoring. Fernando On Thu, Sep 12, 2013 at 1:30 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Fernando, > > Now I see #initializeTranslucentPatterns is there. > > BUT: I expected it ON THE CLASS SIDE since usually initializing class variables is done > with class side methods. This is my opinion also a better style of coding in > Smalltalk. > > For instance if one resets a class variable in the browser: > > TranslucentPatterns := nil. > > or sets it to other values for experiments one can easily reinitialize by sending a > class side message. > > FormCanvas initializeTranslucentPatterns > > No need to create instances (which may be hard to construct in some cases). > > Would you mind moving it to the class side? > > Thx > T. > > >> I found the bug! it is that FormCanvas>>translucentMaskFor: alphaValue >> depth: d, should use the accessor ! >> >> Maybe when my settings our initialised the >> FormCanvas>>translucentPatterns get evaluated... >> >> I'll open an ISSUE and submit the code ASAP. >> >> >> >> >> On Thu, Sep 12, 2013 at 1:12 PM, Fernando Olivero >> <fernando.olivero.mail(a)gmail.com> wrote: >> > Hi,this is strange, because everything works just fine for me. >> > >> > I'm using Pharo3.0: Latest update: #30391 >> > >> > That's ok, the class var is lazy initialized. See >> > FormCanvas>>translucentPatterns. >> > >> > I don't understand which missing method are you referring to, because >> > FormCanvas class>>initializeTranslucentPatterns is there. >> > >> > Are you using #30391 ? >> > >> > Fernando >> > >> > >> > On Thu, Sep 12, 2013 at 1:05 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> >> On Sep 12, 2013, at 12:59 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> >> >>> Marcus wrote: >> >>>> This should be fixed in 3.0 390â¦. at least I can't reproduce it anymore. >> >>> >> >>> Hi Marcus, >> >>> >> >>> No its not. I tried in the latest 3.0 image from today. To make sure I cleanly downloaded a fresh >> >>> Pharo3.0 Latest update: #30391 and still can reproduce the problem. >> >>> One has to do some moving on the Workspace. >> >>> >> >>> If you look you will into an updated image you will also see that still class var >> >>> "TranslucentPatterns" in FormCanvas is uninitialized and class side methods on FormCanvas for >> >>> initialization are missing. So the problem still persists ... >> >> >> >> This is strange. now I can reproduce it, but when I tested it before I could not. >> >> >> >> Marcus >>

Sept. 12, 2013

Re: [Pharo-dev] NBFFI version of the OpenDBXDriver

by Mariano Martinez Peck

On Thu, Sep 12, 2013 at 1:08 AM, Rocio Amaya <rochiamaya(a)gmail.com> wrote: > * > > Hi! > > I'd like to show a bit the outcome of the first iteration of the DBXTalk > Gsoc of this year. > > First, I've been adapting myself to the environment and technology > (DBXTalk, OpenDBX, TalkFFI), and I've written some little tutorials of what > I've learnt about them: > > - Post of how to install OpenDBX > > > http://rochiamaya.wordpress.com/2013/07/28/how-to-install-version-1-4-6-of-… > > - Post of how to install and use TalkFFI to generate mappings > > http://rochiamaya.wordpress.com/2013/07/30/create-bindings-with-talkffi/ > > - Post of how to use mappings generated by TalkFFI > > > http://rochiamaya.wordpress.com/2013/08/06/how-to-use-the-generated-binding… > > > Also, as concrete code, we have built a NBFFI version of the > OpenDBXDriver. The main idea of this is to provide a backward compatibility > layer to people that use OpenDBX, while letting us move forward dropping > the old FFI implementation. > > * > That's all very cool. Thanks Rocio for keep us informed! Much appreciated. Regarding the usage of NBFFI, could you benchmark and see if there is a difference with using the traditional FFI? There used to be a package in DBXTalk with several benchmarks, I am sure you could reuse some.... I can give you more details if you want. > * > > Gofer it > > smalltalkhubUser: 'DBXTalk' project: 'Configurations'; > > configurationOf: 'OpenDBXDriver'; > > load. > > (((Smalltalk at: #ConfigurationOfOpenDBXDriver) > > perform: #project) > > perform: #version: with: â1.3â) > > load: 'DeveloperGroup'. > > > However, the configuration still supports to load the former version of > the driver (no NBFFI) > > Gofer it > > smalltalkhubUser: 'DBXTalk' project: 'Configurations'; > > configurationOf: 'OpenDBXDriver'; > > load. > > (((Smalltalk at: #ConfigurationOfOpenDBXDriver) > > perform: #project) > > perform: #version: with: â1.3â) > > load: 'FFIDriver'. > > > And the configuration with only NBFFI version. > > Gofer it > > smalltalkhubUser: 'DBXTalk' project: 'Configurations'; > > configurationOf: 'OpenDBXDriver'; > > load. > > (((Smalltalk at: #ConfigurationOfOpenDBXDriver) > > perform: #project) > > perform: #version: with: â1.3â) > > load: 'NBFFIDriver'. > > > To use, writte in the Workspace and DoIt: > > > âto set the NBFFI bindâ > > LibOpenDBXMap initialize. > > OpenDBX current: NBPharoOpenDBX new. > > âor to set the oldFFI bindâ > > OpenDBX current: FFIOpenDBX ffiImplementationForOS . > > > In our current/next steps, we are starting to dig into the other driver > implementations. I'm currently working in a Mysql driver implementation > that will use the C mysql library directly without the intermediation of > OpenDBX. That way, the setup of the environment will be far easier and the > entry barrier will be lowered. > > * > To be honest, I don't see the advantages of this. You would avoid dealing with openDBX + mysql libs to be dealing with mysql lib only. But for that purpose there already is a MySQL Smalltalk driver implementation..... Cheers, > * > Best Regards!* > *Rocio.* > > -- > You received this message because you are subscribed to the Google Groups > "DBXTalk" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dbxtalk+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- Mariano http://marianopeck.wordpress.com

Sept. 12, 2013

Re: [Pharo-dev] Workspace Moprh Bug with image 30389

by kilon

its not fixed in 30391 which I just downloaded, at first it appears the problem disappears but as soon as I save the image and reopen it and move the first workspace window and they second workspace window around , they both get the red box. So you may want to have another look at it unless 30391 is not the latest. I got it from here -> http://files.pharo.org/image/30/Pharo-Image-3.0-latest.zip <http://files.pharo.org/image/30/Pharo-Image-3.0-latest.zip> Fernando Olivero-3 wrote > Yes, this happened due to Monticello when integrating the Issue. Is > fixed in the latest image. > > Messing up with Color's is both hazardous and difficult to integrate > in the remote server! I'm having some problems with the integration of > the issue whichs removes TranslucentColor.that I'm tackling now. > > Fernando > > > > > > > On Thu, Sep 12, 2013 at 12:40 PM, Marcus Denker < > marcus.denker@ > > wrote: >> >> On Sep 12, 2013, at 12:36 PM, "Torsten Bergmann" < > astares@ > > wrote: >> >>> kilon wrote: >>>> this happens only when I try to create a new workspace issuing the >>>> commands >>>> you see in the screenshot and it appears after I try to move the new >>>> workspace. At first it appears as a small red box but while hitting >>>> enter it >>>> expands to the final size you see here. >>>> >>>> Are you aware of this bug ? >>> >>> I can reproduce the problem. Looks like some code is missing and leads >>> to an uninitialized >>> class variable: >>> >>> The method #translucentMaskFor:depth: uses a class var >>> "TranslucentPatterns" from FormCanvas. >>> This class variable is nil and therefore it crashes. Looks like there is >>> some initialization >>> on the class side missing. >>> >>> Code is written by Fernando this week (9/11/2013) - so it is brand new. >>> >>> Looks like a side effect of fixing >>> https://pharo.fogbugz.com/f/cases/11559 >>> which was integrated in update #30389 >>> >>> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-September/0… >>> >>> If you look at the second changeset in this issue #11559 it includes an >>> #initializeTranslucentPatterns >>> method from Fernando - but it did not made it correctly into the image. >>> >>> Please open a new bug on http://bugs.pharo.org and maybe Fernando can >>> have a look. >>> >> >> This should be fixed in 3.0 390â¦. at least I can't reproduce it anymore. >> >> Marcus >> -- View this message in context: http://forum.world.st/Workspace-Moprh-Bug-with-image-30389-tp4707816p470784… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 12, 2013

Re: [Pharo-dev] Workspace Moprh Bug with image 30389

by Torsten Bergmann

Hi Fernando, Now I see #initializeTranslucentPatterns is there. BUT: I expected it ON THE CLASS SIDE since usually initializing class variables is done with class side methods. This is my opinion also a better style of coding in Smalltalk. For instance if one resets a class variable in the browser: TranslucentPatterns := nil. or sets it to other values for experiments one can easily reinitialize by sending a class side message. FormCanvas initializeTranslucentPatterns No need to create instances (which may be hard to construct in some cases). Would you mind moving it to the class side? Thx T. > I found the bug! it is that FormCanvas>>translucentMaskFor: alphaValue > depth: d, should use the accessor ! > > Maybe when my settings our initialised the > FormCanvas>>translucentPatterns get evaluated... > > I'll open an ISSUE and submit the code ASAP. > > > > > On Thu, Sep 12, 2013 at 1:12 PM, Fernando Olivero > <fernando.olivero.mail(a)gmail.com> wrote: > > Hi,this is strange, because everything works just fine for me. > > > > I'm using Pharo3.0: Latest update: #30391 > > > > That's ok, the class var is lazy initialized. See > > FormCanvas>>translucentPatterns. > > > > I don't understand which missing method are you referring to, because > > FormCanvas class>>initializeTranslucentPatterns is there. > > > > Are you using #30391 ? > > > > Fernando > > > > > > On Thu, Sep 12, 2013 at 1:05 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> > >> On Sep 12, 2013, at 12:59 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> > >>> Marcus wrote: > >>>> This should be fixed in 3.0 390â¦. at least I can't reproduce it anymore. > >>> > >>> Hi Marcus, > >>> > >>> No its not. I tried in the latest 3.0 image from today. To make sure I cleanly downloaded a fresh > >>> Pharo3.0 Latest update: #30391 and still can reproduce the problem. > >>> One has to do some moving on the Workspace. > >>> > >>> If you look you will into an updated image you will also see that still class var > >>> "TranslucentPatterns" in FormCanvas is uninitialized and class side methods on FormCanvas for > >>> initialization are missing. So the problem still persists ... > >> > >> This is strange. now I can reproduce it, but when I tested it before I could not. > >> > >> Marcus >

Sept. 12, 2013

Re: [Pharo-dev] Workspace Moprh Bug with image 30389

by Fernando Olivero

I found the bug! it is that FormCanvas>>translucentMaskFor: alphaValue depth: d, should use the accessor ! Maybe when my settings our initialised the FormCanvas>>translucentPatterns get evaluated... I'll open an ISSUE and submit the code ASAP. On Thu, Sep 12, 2013 at 1:12 PM, Fernando Olivero <fernando.olivero.mail(a)gmail.com> wrote: > Hi,this is strange, because everything works just fine for me. > > I'm using Pharo3.0: Latest update: #30391 > > That's ok, the class var is lazy initialized. See > FormCanvas>>translucentPatterns. > > I don't understand which missing method are you referring to, because > FormCanvas class>>initializeTranslucentPatterns is there. > > Are you using #30391 ? > > Fernando > > > On Thu, Sep 12, 2013 at 1:05 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Sep 12, 2013, at 12:59 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >> >>> Marcus wrote: >>>> This should be fixed in 3.0 390â¦. at least I can't reproduce it anymore. >>> >>> Hi Marcus, >>> >>> No its not. I tried in the latest 3.0 image from today. To make sure I cleanly downloaded a fresh >>> Pharo3.0 Latest update: #30391 and still can reproduce the problem. >>> One has to do some moving on the Workspace. >>> >>> If you look you will into an updated image you will also see that still class var >>> "TranslucentPatterns" in FormCanvas is uninitialized and class side methods on FormCanvas for >>> initialization are missing. So the problem still persists ... >> >> This is strange. now I can reproduce it, but when I tested it before I could not. >> >> Marcus

Sept. 12, 2013

Re: [Pharo-dev] Workspace Moprh Bug with image 30389

by Fernando Olivero

Hi,this is strange, because everything works just fine for me. I'm using Pharo3.0: Latest update: #30391 That's ok, the class var is lazy initialized. See FormCanvas>>translucentPatterns. I don't understand which missing method are you referring to, because FormCanvas class>>initializeTranslucentPatterns is there. Are you using #30391 ? Fernando On Thu, Sep 12, 2013 at 1:05 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Sep 12, 2013, at 12:59 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> Marcus wrote: >>> This should be fixed in 3.0 390â¦. at least I can't reproduce it anymore. >> >> Hi Marcus, >> >> No its not. I tried in the latest 3.0 image from today. To make sure I cleanly downloaded a fresh >> Pharo3.0 Latest update: #30391 and still can reproduce the problem. >> One has to do some moving on the Workspace. >> >> If you look you will into an updated image you will also see that still class var >> "TranslucentPatterns" in FormCanvas is uninitialized and class side methods on FormCanvas for >> initialization are missing. So the problem still persists ... > > This is strange. now I can reproduce it, but when I tested it before I could not. > > Marcus

Sept. 12, 2013

Naming of Global Session

by Torsten Bergmann

In Pharo 3.0 there is a new class "Session" - to represent the current smalltalk session. Using the term "Session" is very abstract. IMHO I would rather like to see it named more specific like "ImageSession", "PharoSession" or "SmalltalkSession" before it get used too much. Any comments? T.

Sept. 12, 2013

Re: [Pharo-dev] NBOpengl Error : IcompatibleLayoutConflict

by Igor Stasenko

This should be fixed. It easy to fix, just had no time to update things in all projects. Basically, what needed is to save package version, which has no subclasses of NBExternalStructure, and then take new image and manually reintroduce all NBExternalStructure subclasses (use fileout/filein mechanism) and then save a new MC packages, where these classes in right format. Please read details here: https://groups.google.com/forum/#!topic/nativeboost/3Ik3UtLGMGo On 12 September 2013 09:34, kilon <thekilon(a)yahoo.co.uk> wrote: > ok so you talk about live objects, i see. Nonetheless I assume that it will > still install NBOpenGL fully without any problems. The problem is instance > objects that I may be using at the time. > > > > -- > View this message in context: > http://forum.world.st/NBOpengl-Error-IcompatibleLayoutConflict-tp4707721p47… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Best regards, Igor Stasenko.

Sept. 12, 2013

Re: [Pharo-dev] Workspace Moprh Bug with image 30389

by Marcus Denker

On Sep 12, 2013, at 12:59 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Marcus wrote: >> This should be fixed in 3.0 390â¦. at least I can't reproduce it anymore. > > Hi Marcus, > > No its not. I tried in the latest 3.0 image from today. To make sure I cleanly downloaded a fresh > Pharo3.0 Latest update: #30391 and still can reproduce the problem. > One has to do some moving on the Workspace. > > If you look you will into an updated image you will also see that still class var > "TranslucentPatterns" in FormCanvas is uninitialized and class side methods on FormCanvas for > initialization are missing. So the problem still persists ... This is strange. now I can reproduce it, but when I tested it before I could not. Marcus

Sept. 12, 2013