January 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Glorp on Pharo 4

by Craig

Thanks Torsten, The guide worked right out of the box. Many thanks for your help. Craig -----Original Message----- From: Torsten Bergmann [mailto:astares@gmx.de] Sent: 20 January 2015 11:42 AM To: craig(a)hivemind.net; Any question about pharo is welcome Subject: Glorp on Pharo 4 Hi Craig, see below a quick guide. Tell me when it works. Someone should do a video from that... Thanks Torsten ------------------------------------------------------------------------------------------------------------------------------------------------ For Windows: ============ - go to http://www.sqlite.org/download.html and retrieve sqlite-dll-win32-x86-3080800.zip - copy the included sqlite3.dll to the folder where your virtual machine (Pharo.exe) resides so it can be found by the NativeBoost wrapper later (as an alternative you can have in any folder that is accessible via PATH environment variable) - open a fresh Pharo4.0 image (here I use latest update: #40451 image) - load from ConfigurationBrowser: "Glorp" - load from ConfigurationBrowser: "NBSQLite3" - then open Monticello browser and select the repo for NBSQLite3, open it and load additionally "NBSQLite3-Glorp-TorstenBergmann.3" - create a package "Killerapp-Core" using Nautilus system browser - create a tag "Model" in this new package using Nautilus system browser - create a class Object subclass: #KillerAppUser instanceVariableNames: 'id username' classVariableNames: '' category: 'Killerapp-Core-Model' - click on the class in Nautilus browser and select "Refactoring" -> "Class Refactoring" and "Generate Accessors" to create accessor methods for the instance variables - create a package "Killerapp-Persistence" using Nautilus system browser - create a tag "Mappings" in this new package using Nautilus system browser DescriptorSystem subclass: #KillerAppDatabaseDescriptor instanceVariableNames: '' classVariableNames: '' category: 'Killerapp-Persistence-Mappings' - implement an instance side method in method category 'accessing' allTableNames ^ #('KILLERAPP_USER') - create an instance side method in category 'mapping-classes' constructAllClasses ^ super constructAllClasses add: KillerAppUser; yourself - implement an instance side method in method category 'mapping - classes' classModelForKillerAppUser: aClassModel #(#id #username) do: [ :each | aClassModel newAttributeNamed: each ] - create an instance side method in method category 'mapping - descriptors' descriptorForKillerAppUser: aDescriptor | table | table := self tableNamed: 'KILLERAPP_USER'. aDescriptor table: table. #(id username) do: [ :each | (aDescriptor newMapping: DirectMapping) from: each to: (table fieldNamed: each) ] - implement an instance side method in method category 'mapping - tables' tableForKILLERAPP_USER: aTable "Define the table KILLERAPP_USER" (aTable createFieldNamed: 'ID' type: platform sequence) isUnique: true; bePrimaryKey. (aTable createFieldNamed: 'USERNAME' type: (platform varchar: 20)) isUnique: true; beNullable: false. By having the descriptions set up you can now play with Glorp: |login accessor session| login := Login new. login host: ''. login databaseName: 'C:\db\killerapp.db'. login database: SQLite3Platform new. accessor := NBSQLite3DatabaseAccessor forLogin: login. accessor loginIfError: [ self error: 'unable to connect' ]. session := GlorpSession new. session system: (KillerAppDatabaseDescriptor forPlatform: login database). session accessor: accessor. "Create all tables (only to be done once)" session createTables. "Create a new user" session inUnitOfWorkDo: [ user := (KillerAppUser new) username: 'admin'. session register: user ]. Then you can use a tool like "SQLiteStudio" to open the database and check what is in the tables...

Jan. 20, 2015

Re: [Pharo-users] Code highlight

by Mark Rizun

I opened a case https://pharo.fogbugz.com/f/cases/14756/ Anywhay, anybody knows what this method #whenReadSelectionIsChanged: is responsible for? 2015-01-20 9:58 GMT+01:00 Mark Rizun <mrizun(a)gmail.com>: > I had a quick look. I confirm that TextModel keeps a value holder on the >> current selection interval, in the instance variable named âselection', but >> apparently there is no API to register to notifications to that. I consider >> that a missing feature, so I think it is best that you add a bug report for >> that. >> > Exactly! I think so too: it's just missing, and has to be fixed. I'll open > an issue > Thanks > > >> In the mean time, Iâm sure you could hack something together that >> registers your application for notifications of the value holder that is in >> âselectionâ ;-) >> > At least I can try to figure it out. > > Mark >

Jan. 20, 2015

Re: [Pharo-users] "Improper store into indexable object" and weird variable names

by Sven Van Caekenberghe

> On 20 Jan 2015, at 10:48, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Typically, if the image can still access the change file but not the source file (or the other way around), some methods still show temporary variable names, whereas other methods show t1, t2, etc , depending on which files their sources were in. Yes, that is what I asked, but he said 'both'... > > > 2015-01-20 10:21 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 20 Jan 2015, at 10:00, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > > > > Date: 20 Jan 2015 09:56:45 CET > > From: Davide Varvello <varvello(a)yahoo.com> > > To: pharo-users(a)lists.pharo.org > > Subject: Re: "Improper store into indexable object" and weird variable names > > > > > > Sven Van Caekenberghe-2 wrote > >>> On 19 Jan 2015, at 22:46, Davide Varvello via Pharo-users < > > > >> pharo-users@.pharo > > > >> > wrote: > >>> > >>> > >>> Date: 19 Jan 2015 22:43:13 CET > >>> From: Davide Varvello < > > > >> varvello@ > > > >> > > >>> To: > > > >> pharo-users@.pharo > > > >>> Subject: Re: "Improper store into indexable object" and weird variable > >>> names > >>> > >>> > >>> H Sven, > >>> I didn't move nor rename any of them. In fact some methods have t1, t2, > >>> t3, > >>> ... but some others have real variable names. > >> > >> That is weird. Any details on which work and which do not ? System code or > >> your code ? > > > > Both, my code and system code. Looking at changes it seems it lost all code > > before 7:01:06 pm CET of yesterday (see http://imgur.com/V8eis9Z) I can try > > to restore from my backup, but I'm wondering what happened. > > It has been years that I developed in 2.0, but I very vaguely remember having seen something similar. Going back and recovering from backup seems the only choice. > > I find it hard to believe that, say some Collection methods are OK, and some say String methods are decompiled, and some of your own code is OK and some is not - totally arbitrary ? Is it even constant ? > > > Davide > > > > > > > > -- > > View this message in context: http://forum.world.st/Improper-store-into-indexable-object-and-weird-variab… > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > > >

Jan. 20, 2015

Re: [Pharo-users] "Improper store into indexable object" and weird variable names

by ClÃ©ment Bera

Typically, if the image can still access the change file but not the source file (or the other way around), some methods still show temporary variable names, whereas other methods show t1, t2, etc , depending on which files their sources were in. 2015-01-20 10:21 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 20 Jan 2015, at 10:00, Davide Varvello via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > > > > > > Date: 20 Jan 2015 09:56:45 CET > > From: Davide Varvello <varvello(a)yahoo.com> > > To: pharo-users(a)lists.pharo.org > > Subject: Re: "Improper store into indexable object" and weird variable > names > > > > > > Sven Van Caekenberghe-2 wrote > >>> On 19 Jan 2015, at 22:46, Davide Varvello via Pharo-users < > > > >> pharo-users@.pharo > > > >> > wrote: > >>> > >>> > >>> Date: 19 Jan 2015 22:43:13 CET > >>> From: Davide Varvello < > > > >> varvello@ > > > >> > > >>> To: > > > >> pharo-users@.pharo > > > >>> Subject: Re: "Improper store into indexable object" and weird variable > >>> names > >>> > >>> > >>> H Sven, > >>> I didn't move nor rename any of them. In fact some methods have t1, t2, > >>> t3, > >>> ... but some others have real variable names. > >> > >> That is weird. Any details on which work and which do not ? System code > or > >> your code ? > > > > Both, my code and system code. Looking at changes it seems it lost all > code > > before 7:01:06 pm CET of yesterday (see http://imgur.com/V8eis9Z) I > can try > > to restore from my backup, but I'm wondering what happened. > > It has been years that I developed in 2.0, but I very vaguely remember > having seen something similar. Going back and recovering from backup seems > the only choice. > > I find it hard to believe that, say some Collection methods are OK, and > some say String methods are decompiled, and some of your own code is OK and > some is not - totally arbitrary ? Is it even constant ? > > > Davide > > > > > > > > -- > > View this message in context: > http://forum.world.st/Improper-store-into-indexable-object-and-weird-variab… > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > > >

Jan. 20, 2015

Glorp on Pharo 4

by Torsten Bergmann

Hi Craig, see below a quick guide. Tell me when it works. Someone should do a video from that... Thanks Torsten ------------------------------------------------------------------------------------------------------------------------------------------------ For Windows: ============ - go to http://www.sqlite.org/download.html and retrieve sqlite-dll-win32-x86-3080800.zip - copy the included sqlite3.dll to the folder where your virtual machine (Pharo.exe) resides so it can be found by the NativeBoost wrapper later (as an alternative you can have in any folder that is accessible via PATH environment variable) - open a fresh Pharo4.0 image (here I use latest update: #40451 image) - load from ConfigurationBrowser: "Glorp" - load from ConfigurationBrowser: "NBSQLite3" - then open Monticello browser and select the repo for NBSQLite3, open it and load additionally "NBSQLite3-Glorp-TorstenBergmann.3" - create a package "Killerapp-Core" using Nautilus system browser - create a tag "Model" in this new package using Nautilus system browser - create a class Object subclass: #KillerAppUser instanceVariableNames: 'id username' classVariableNames: '' category: 'Killerapp-Core-Model' - click on the class in Nautilus browser and select "Refactoring" -> "Class Refactoring" and "Generate Accessors" to create accessor methods for the instance variables - create a package "Killerapp-Persistence" using Nautilus system browser - create a tag "Mappings" in this new package using Nautilus system browser DescriptorSystem subclass: #KillerAppDatabaseDescriptor instanceVariableNames: '' classVariableNames: '' category: 'Killerapp-Persistence-Mappings' - implement an instance side method in method category 'accessing' allTableNames ^ #('KILLERAPP_USER') - create an instance side method in category 'mapping-classes' constructAllClasses ^ super constructAllClasses add: KillerAppUser; yourself - implement an instance side method in method category 'mapping - classes' classModelForKillerAppUser: aClassModel #(#id #username) do: [ :each | aClassModel newAttributeNamed: each ] - create an instance side method in method category 'mapping - descriptors' descriptorForKillerAppUser: aDescriptor | table | table := self tableNamed: 'KILLERAPP_USER'. aDescriptor table: table. #(id username) do: [ :each | (aDescriptor newMapping: DirectMapping) from: each to: (table fieldNamed: each) ] - implement an instance side method in method category 'mapping - tables' tableForKILLERAPP_USER: aTable "Define the table KILLERAPP_USER" (aTable createFieldNamed: 'ID' type: platform sequence) isUnique: true; bePrimaryKey. (aTable createFieldNamed: 'USERNAME' type: (platform varchar: 20)) isUnique: true; beNullable: false. By having the descriptions set up you can now play with Glorp: |login accessor session| login := Login new. login host: ''. login databaseName: 'C:\db\killerapp.db'. login database: SQLite3Platform new. accessor := NBSQLite3DatabaseAccessor forLogin: login. accessor loginIfError: [ self error: 'unable to connect' ]. session := GlorpSession new. session system: (KillerAppDatabaseDescriptor forPlatform: login database). session accessor: accessor. "Create all tables (only to be done once)" session createTables. "Create a new user" session inUnitOfWorkDo: [ user := (KillerAppUser new) username: 'admin'. session register: user ]. Then you can use a tool like "SQLiteStudio" to open the database and check what is in the tables...

Jan. 20, 2015

Re: [Pharo-users] "Improper store into indexable object" and weird variable names

by Sven Van Caekenberghe

> On 20 Jan 2015, at 10:00, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > Date: 20 Jan 2015 09:56:45 CET > From: Davide Varvello <varvello(a)yahoo.com> > To: pharo-users(a)lists.pharo.org > Subject: Re: "Improper store into indexable object" and weird variable names > > > Sven Van Caekenberghe-2 wrote >>> On 19 Jan 2015, at 22:46, Davide Varvello via Pharo-users < > >> pharo-users@.pharo > >> > wrote: >>> >>> >>> Date: 19 Jan 2015 22:43:13 CET >>> From: Davide Varvello < > >> varvello@ > >> > >>> To: > >> pharo-users@.pharo > >>> Subject: Re: "Improper store into indexable object" and weird variable >>> names >>> >>> >>> H Sven, >>> I didn't move nor rename any of them. In fact some methods have t1, t2, >>> t3, >>> ... but some others have real variable names. >> >> That is weird. Any details on which work and which do not ? System code or >> your code ? > > Both, my code and system code. Looking at changes it seems it lost all code > before 7:01:06 pm CET of yesterday (see http://imgur.com/V8eis9Z) I can try > to restore from my backup, but I'm wondering what happened. It has been years that I developed in 2.0, but I very vaguely remember having seen something similar. Going back and recovering from backup seems the only choice. I find it hard to believe that, say some Collection methods are OK, and some say String methods are decompiled, and some of your own code is OK and some is not - totally arbitrary ? Is it even constant ? > Davide > > > > -- > View this message in context: http://forum.world.st/Improper-store-into-indexable-object-and-weird-variab… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > >

Jan. 20, 2015

Re: [Pharo-users] Code highlight

by Mark Rizun

> > I had a quick look. I confirm that TextModel keeps a value holder on the > current selection interval, in the instance variable named âselection', but > apparently there is no API to register to notifications to that. I consider > that a missing feature, so I think it is best that you add a bug report for > that. > Exactly! I think so too: it's just missing, and has to be fixed. I'll open an issue Thanks > In the mean time, Iâm sure you could hack something together that > registers your application for notifications of the value holder that is in > âselectionâ ;-) > At least I can try to figure it out. Mark

Jan. 20, 2015

Re: "Improper store into indexable object" and weird variable names

by Davide Varvello

Sven Van Caekenberghe-2 wrote >> On 19 Jan 2015, at 22:46, Davide Varvello via Pharo-users < > pharo-users@.pharo > > wrote: >> >> >> Date: 19 Jan 2015 22:43:13 CET >> From: Davide Varvello < > varvello@ > > >> To: > pharo-users@.pharo >> Subject: Re: "Improper store into indexable object" and weird variable >> names >> >> >> H Sven, >> I didn't move nor rename any of them. In fact some methods have t1, t2, >> t3, >> ... but some others have real variable names. > > That is weird. Any details on which work and which do not ? System code or > your code ? Both, my code and system code. Looking at changes it seems it lost all code before 7:01:06 pm CET of yesterday (see http://imgur.com/V8eis9Z) I can try to restore from my backup, but I'm wondering what happened. Davide -- View this message in context: http://forum.world.st/Improper-store-into-indexable-object-and-weird-variab… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 20, 2015

Re: [Pharo-users] [Pharo-dev] OpenStreetMap integration

by Serge Stinckwich

Terrific !!! On Mon, Jan 19, 2015 at 3:19 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Dear All, > > This week end I have integrated the excellent work of Onil Goubier and > Thierry Goubier. They have worked on a bridge between OpenStreetMap and > Roassal. As a result, you can easily decorate a map with element describing > metrics and properties of geolocation. Consider the following: > > I think the following screenshot should be self-explanatory: > > > Below are some results of 10lines-long scripts. Seisms during the last 30 > days: > > Refugies monitored by the United Nations High Commissioner for Refugees: > > We started to write a chapter for Agile Visualization. Here it is: > > > https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/OpenStreetM… > > Again, thanks Onil and Thierry. This is a very valuable contribution for > the whole community! > > Cheers, > Alexandre > > NB: Sorry for the cross-post, but I believe the content of this email goes > well beyond to the Moose people interest. > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Jan. 20, 2015

Re: [Pharo-users] "Improper store into indexable object" and weird variable names

by Sven Van Caekenberghe

> On 19 Jan 2015, at 22:46, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > Date: 19 Jan 2015 22:43:13 CET > From: Davide Varvello <varvello(a)yahoo.com> > To: pharo-users(a)lists.pharo.org > Subject: Re: "Improper store into indexable object" and weird variable names > > > H Sven, > I didn't move nor rename any of them. In fact some methods have t1, t2, t3, > ... but some others have real variable names. That is weird. Any details on which work and which do not ? System code or your code ? > Davide > > > Sven Van Caekenberghe-2 wrote >> Hi Davide, >> >> That means you are looking at decompiled code, because the system can no >> longer access the source code. Source code lives either in the .sources or >> .changes file. Did you move or rename any of them ? >> >> Sven >> >>> On 19 Jan 2015, at 22:22, Davide Varvello via Pharo-users < > >> pharo-users@.pharo > >> > wrote: >>> >>> >>> Date: 19 Jan 2015 22:19:37 CET >>> From: Davide Varvello < > >> varvello@ > >> > >>> To: > >> pharo-users@.pharo > >>> Subject: "Improper store into indexable object" and weird variable names >>> >>> >>> Hi! >>> >>> It happened that variables of my methods changed to t1, t2, t3, etc etc >>> (see >>> here: http://imgur.com/ptbmzMH ) and when I try to see the versions of a >>> method, pharo shows "Improper store into indexable object" (see here: >>> http://imgur.com/pwWT0yc ). >>> >>> Can you help me, please? I'm on Pharo2.0, Latest update: #20619 >>> >>> Cheers >>> Davide >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Improper-store-into-indexable-object-and-weird-variab… >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >>> >>> > > > > > > -- > View this message in context: http://forum.world.st/Improper-store-into-indexable-object-and-weird-variab… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 20, 2015