[Pharo-users] PunQLite jx9 Documentation

[Gareth Cox]

Hi All

I'm using PunQLite for a prototype I'm developing.
I'd like to find out more about how to do the jx9 stuff with PunQLite.
I see there are examples to run simple jx9 code, but I was hoping to 
find something more detailed, like how to query, filter, or work with 
the database using jx9.


KR
--
Gareth Cox
IT Manager/Developer
Inspired Org (PTY) Ltd
email: gar...@inspired.org 
tell: +27 (0)21 531 5404
cell: +27 (0)78 374 9035

[Pharo-users] Boardician update

[Laura Risani]

Hi all,

Made an update, main changes :
added BgMines game,
added dual arrow/keyboard pointing support (try BgMines),
refactored BGHuman and it's subclasses,
displaying the menu pauses the game,
redesigned the menu.

Any feedback is welcome. In particular functionalities to add, games to
implement, suggestions on how to enhance a little the games' look.


What's Boardician?
It is a framework for building board games. You can install it from
configuration BgBoardician at Configuration Browser on 3.0 and 4.0 . D
ocumentation here


Best,
Laura

Re: [Pharo-users] Some Pharo 4 Getting-Started tips

[Offray Vladimir Luna Cárdenas]

El 26/05/15 a las 17:59, Avdi Grimm escribió:


If you can keep distinctive project names, but also name menus and title bars
such that they link the distinct project to the *role* that project plays,
you've got the best of both worlds.


That is, for me the best approach also.

Cheers,

Offray

[Pharo-users] How to move data between Pharo versions

[PBKResearch]

Hello

 

I have found a way round this problem, but it seems messy and uncomfortable,
so I thought I should ask what is the right way to do it.

 

I have just changed from using Moose 5.0 (Pharo 3.0, update: #30862) to
Moose 5.1 (Pharo 4.0, update: #40613). I had a rather complex dictionary
structure in a Playground in 5.0, which I wanted to reproduce exactly in the
5.1 image. Looking around, Fuel looked like the obvious tool to save and
restore the structure. It saved OK in 5.0, but when I tried to
re-materialize it in 5.1 I got an error message: 'FLBadVersion:
Materialization error. Unexpected stream vers' (can't see the rest of the
message). I could see from the debugger output that Fuel was looking for
version 194 and seeing 193. Using a brute force approach, I hacked
FLSerializer class >> currentVersion in the Moose 5.0 image to return 194
instead 193, then tried again, and of course everything worked OK.

 

My question is what should I have done? How can I move data from one image
to another of a later version? If Fuel has no backward compatibility, is
there another tool I can use?

 

Thanks for any advice

 

Peter Kenny

Re: [Pharo-users] How to move data between Pharo versions

[Sven Van Caekenberghe]

> On 28 May 2015, at 18:18, PBKResearch  wrote:
> 
> Hello
>  
> I have found a way round this problem, but it seems messy and uncomfortable, 
> so I thought I should ask what is the right way to do it.
>  
> I have just changed from using Moose 5.0 (Pharo 3.0, update: #30862) to Moose 
> 5.1 (Pharo 4.0, update: #40613). I had a rather complex dictionary structure 
> in a Playground in 5.0, which I wanted to reproduce exactly in the 5.1 image. 
> Looking around, Fuel looked like the obvious tool to save and restore the 
> structure. It saved OK in 5.0, but when I tried to re-materialize it in 5.1 I 
> got an error message: ‘FLBadVersion: Materialization error. Unexpected stream 
> vers’ (can’t see the rest of the message). I could see from the debugger 
> output that Fuel was looking for version 194 and seeing 193. Using a brute 
> force approach, I hacked FLSerializer class >> currentVersion in the Moose 
> 5.0 image to return 194 instead 193, then tried again, and of course 
> everything worked OK.
>  
> My question is what should I have done? How can I move data from one image to 
> another of a later version? If Fuel has no backward compatibility, is there 
> another tool I can use?

Depending on what the data is, STON can be quite useful.

https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/STON/STON.html

> Thanks for any advice
>  
> Peter Kenny

Re: [Pharo-users] How to move data between Pharo versions

[Sean P. DeNigris]

Peter Kenny wrote
> My question is what should I have done?

There is usually an overlap between the Fuel versions loadable in
consecutive Pharo versions, so you have to either (via Metacello) upgrade
the Fuel in your source image, or downgrade in the target image, so that you
can save and move the data without conflict.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/How-to-move-data-between-Pharo-versions-tp4829102p4829115.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Some Pharo 4 Getting-Started tips

[stepharo]

I like your point.
Please keep idiosyncratic names because we can build marketing with them.
My computer is not just Computer your phone is not just Phone :)
Even your shoes are not Shoes

So brands are important
Pharo is not Programming Language!


Le 27/5/15 00:59, Avdi Grimm a écrit :



On Tue, May 26, 2015 at 1:27 PM Esteban Lorenzano > wrote:



or we can rename it as "System Browser (Nautilus)” in the title,
or something like that



I think this is ideal.

I remember back when I used to use Perl, and it had CPAN, which was 
great. The only problem was that someone would say "use the XML 
library!" and you'd look in CPAN and there'd be xml and xmllib and 
libxml and  fastxml or whatever, and you'd be like "uh... which one 
would that be?"


Ruby went the other way entirely, with idiosyncratic names like 
"Nokogiri". The obvious down side is that if you see that in an app's 
dependencies and you're a newbie, you have no fricking clue what it 
is. The upside, though, is that if someone tells you "use Nokogiri!" 
there is zero ambiguity about what you're supposed to use. It gives 
the project a distinct, memorable personality.


If you can keep distinctive project names, but also name menus and 
title bars such that they link the distinct project to the *role* that 
project plays, you've got the best of both worlds.

[Pharo-users] Diffing Monticello package against image contents

[Esteban A. Maringolo]

Is there a way to compare the contents of a Monticello package (mcz)
against the contents of the image *REGARDLESS* of the packaging?

It is... I want to compare methods and class definitions from a mcz,
that has a monolithic package (PostgresV3 in this case) against what I
have loaded in the image, which has different packages
(PostgresV3-Core, etc.).

As it is today, if I select PostgresV3.mcz and select the "Changes"
menu, it will mark everything as changed, because such package doesn't
exist in the image.

If PackageA contains a method ClassX>>#methodA, I want the contents of
such method to be compared to what I have in the image, no matter if
ClassX>>#methodA belongs to PackageB or PackageC.

Does such feature exist? Something like a chunks browser, but using a
Monticello package instead of a chunk file.


Esteban A. Maringolo

Re: [Pharo-users] Some Pharo 4 Getting-Started tips

[Sean P. DeNigris]

stepharo wrote
> My computer is not just Computer your phone is not just Phone :)

Well the name iPhone is actually pretty much just Phone! Also, note that
it's not called iConchShell ;) And, the apps it contains are called
Messages, Mail, and Phone. Similarly, Pharo is our brand, and within the
image we can make things simple for everyone. Float does not have to be
branded as Irrational by Calvin Klein, with mathcing unintelligible
commercial advertisements :-p



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Some-Pharo-4-Getting-Started-tips-tp4828493p4829167.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Some Pharo 4 Getting-Started tips

[Esteban A. Maringolo]

2015-05-28 17:44 GMT-03:00 Sean P. DeNigris :
> stepharo wrote
>> My computer is not just Computer your phone is not just Phone :)
>
> Well the name iPhone is actually pretty much just Phone! Also, note that
> it's not called iConchShell ;)

Android Phone, Windows Phone...

> Similarly, Pharo is our brand, and within the
> image we can make things simple for everyone.

Plus, the menu already shows "System browser" as one of the options,
you click it and it opens... Nautilus :P




Esteban A. Maringolo

Re: [Pharo-users] Diffing Monticello package against image contents

[Stephan Eggermont]

On 28-05-15 22:15, Esteban A. Maringolo wrote:

Is there a way to compare the contents of a Monticello package (mcz)
against the contents of the image *REGARDLESS* of the packaging?


If you browse the monolithic package, you have it somewhere in
the image. You should be able to calculate a diff from there.

Stephna

Re: [Pharo-users] Diffing Monticello package against image contents

[Esteban A. Maringolo]

2015-05-28 19:48 GMT-03:00 Stephan Eggermont :
> On 28-05-15 22:15, Esteban A. Maringolo wrote:

>> Is there a way to compare the contents of a Monticello package (mcz)
>> against the contents of the image *REGARDLESS* of the packaging?

> If you browse the monolithic package, you have it somewhere in
> the image. You should be able to calculate a diff from there.

I know I'd could (It's Smalltalk after all). But I wanted to know
whether the "feature" was already available. By your answer I guess
it's not a feature yet.

Thank you!

Esteban A. Maringolo

Re: [Pharo-users] How to move data between Pharo versions

[PBKResearch]

Sean

Thanks for this. At the back of my mind in asking was whether I want to use
Fuel more extensively as a way of storing object structures long term on
disk. If I move to Pharo 5 later on, will that have a new version of Fuel
which will refuse to read my saved files, so that I will have to convert all
my files to the new version?  As far as I can see, I could not do that using
the device you suggest; I would have to have one version of Fuel which could
materialize files of version 193 and re-serialize to version 194. I see that
both FLSerializer and FLMaterializer have class side methods called
#currentVersion; could I set those to give different version numbers, and do
the conversion that way?

Alternatively, I could use Sven's suggestion of STON, provided that will not
go the way of version changes without backward compatibility. I suppose a
lot will depend on the efficiency of the two approaches, both in terms of
storage space on disk and in conversion times.

Thanks to both for the suggestions. I have food for thought and ideas for
further experiment.

Peter Kenny

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of
Sean P. DeNigris
Sent: 28 May 2015 17:39
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] How to move data between Pharo versions

Peter Kenny wrote
> My question is what should I have done?

There is usually an overlap between the Fuel versions loadable in
consecutive Pharo versions, so you have to either (via Metacello) upgrade
the Fuel in your source image, or downgrade in the target image, so that you
can save and move the data without conflict.



-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/How-to-move-data-between-Pharo-versions-tp4829102p4829
115.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] How to move data between Pharo versions

[Sean P. DeNigris]

Peter Kenny wrote
> I will have to convert all my files to the new version?  As far as I can
> see, I could not do that using
> the device you suggest

The thing is that it's only the serialization that is tied to a Fuel
version, so the workflow is (and I've done this to port my data from Pharo
3.0 to Pharo 4.0 and then to Pharo 5.0):

1. In the older image with the data, upgrade Fuel to the latest version that
will load in that Pharo `ConfigurationOfFuel project stableVersion load`
2. Serialize the data
If the Fuel version in #1 is the one that comes with the newer Pharo you're
porting to, you're done. You can now materialize in the newer Pharo version.
Otherwise...
3. In the newer Pharo
  a. Downgrade Fuel e.g `(ConfigurationOfFuel project version:
versionStringFromNumberOneAbove) load`
  b. Materialize the data
  c. Upgrade Fuel back to the normal version for the newer Pharo (replace
version string from 3.a. with the original version)
  d. Serialize the data

Now you can load the data into the newer Pharo.


Peter Kenny wrote
> could I set those to give different version numbers

The problem is that the data format may not be compatible between the
versions. Mariano would be able to give a better answer, but I would be
afraid. What if it seems to work but corrupts your data?!

Does the workflow I detailed make sense and cover your needs?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/How-to-move-data-between-Pharo-versions-tp4829102p4829210.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] How to move data between Pharo versions

[Ben Coman]

On Fri, May 29, 2015 at 7:17 AM, Sean P. DeNigris  wrote:
> Peter Kenny wrote
>> I will have to convert all my files to the new version?  As far as I can
>> see, I could not do that using
>> the device you suggest
>
> The thing is that it's only the serialization that is tied to a Fuel
> version, so the workflow is (and I've done this to port my data from Pharo
> 3.0 to Pharo 4.0 and then to Pharo 5.0):
>
> 1. In the older image with the data, upgrade Fuel to the latest version that
> will load in that Pharo `ConfigurationOfFuel project stableVersion load`

This does not cater for "storing object structures long term on
disk."  I guess the workaround is that the image used to store the
objects needs to archive near the fuel files. But you'd need to be
careful not to save it once you upgraded fuel versions.

> 2. Serialize the data
> If the Fuel version in #1 is the one that comes with the newer Pharo you're
> porting to, you're done. You can now materialize in the newer Pharo version.
> Otherwise...
> 3. In the newer Pharo
>   a. Downgrade Fuel e.g `(ConfigurationOfFuel project version:
> versionStringFromNumberOneAbove) load`
 >   b. Materialize the data
>   c. Upgrade Fuel back to the normal version for the newer Pharo (replace
> version string from 3.a. with the original version)
>   d. Serialize the data

Some use cases may require multiple downgrades/upgrades, which could
be annoying. An interesting idea might be for a new release of Fuel to
rename the previous version of as OldFuel that is released in its own
package. Then "some OldFuel version" could exist in parallel with the
"current version." The "current version" might even be smart enough to
identify the OldFuel version needed and load it into the image and
continue materializing the data.  A CI program might run through a
range of OldFuel versions to track which remain working on future
versions of Pharo.
cheers -ben

>
> Now you can load the data into the newer Pharo.
>
>
> Peter Kenny wrote
>> could I set those to give different version numbers
>
> The problem is that the data format may not be compatible between the
> versions. Mariano would be able to give a better answer, but I would be
> afraid. What if it seems to work but corrupts your data?!

>
> Does the workflow I detailed make sense and cover your needs?
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/How-to-move-data-between-Pharo-versions-tp4829102p4829210.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>

Re: [Pharo-users] How to move data between Pharo versions

[Mariano Martinez Peck]

This thread may help you: http://forum.world.st/Fuel-version-td4823170.html

Cheers,

On Thu, May 28, 2015 at 9:19 PM, Ben Coman  wrote:

> On Fri, May 29, 2015 at 7:17 AM, Sean P. DeNigris 
> wrote:
> > Peter Kenny wrote
> >> I will have to convert all my files to the new version?  As far as I can
> >> see, I could not do that using
> >> the device you suggest
> >
> > The thing is that it's only the serialization that is tied to a Fuel
> > version, so the workflow is (and I've done this to port my data from
> Pharo
> > 3.0 to Pharo 4.0 and then to Pharo 5.0):
> >
> > 1. In the older image with the data, upgrade Fuel to the latest version
> that
> > will load in that Pharo `ConfigurationOfFuel project stableVersion load`
>
> This does not cater for "storing object structures long term on
> disk."  I guess the workaround is that the image used to store the
> objects needs to archive near the fuel files. But you'd need to be
> careful not to save it once you upgraded fuel versions.
>
> > 2. Serialize the data
> > If the Fuel version in #1 is the one that comes with the newer Pharo
> you're
> > porting to, you're done. You can now materialize in the newer Pharo
> version.
> > Otherwise...
> > 3. In the newer Pharo
> >   a. Downgrade Fuel e.g `(ConfigurationOfFuel project version:
> > versionStringFromNumberOneAbove) load`
>  >   b. Materialize the data
> >   c. Upgrade Fuel back to the normal version for the newer Pharo (replace
> > version string from 3.a. with the original version)
> >   d. Serialize the data
>
> Some use cases may require multiple downgrades/upgrades, which could
> be annoying. An interesting idea might be for a new release of Fuel to
> rename the previous version of as OldFuel that is released in its own
> package. Then "some OldFuel version" could exist in parallel with the
> "current version." The "current version" might even be smart enough to
> identify the OldFuel version needed and load it into the image and
> continue materializing the data.  A CI program might run through a
> range of OldFuel versions to track which remain working on future
> versions of Pharo.
> cheers -ben
>
> >
> > Now you can load the data into the newer Pharo.
> >
> >
> > Peter Kenny wrote
> >> could I set those to give different version numbers
> >
> > The problem is that the data format may not be compatible between the
> > versions. Mariano would be able to give a better answer, but I would be
> > afraid. What if it seems to work but corrupts your data?!
>
> >
> > Does the workflow I detailed make sense and cover your needs?
> >
> >
> >
> > -
> > Cheers,
> > Sean
> > --
> > View this message in context:
> http://forum.world.st/How-to-move-data-between-Pharo-versions-tp4829102p4829210.html
> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> >
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-users] Problem with debugging methods

[Marcus Denker]

Can you send my an image saved in that state? 

> On 28 May 2015, at 17:27, Juraj Kubelka  wrote:
> 
> Hi, 
> 
> regularly I cannot debug methods because nil does not understand 
> #compilationContext in method 
> RBMessageNode>>isInlined 
>   self methodNode compilationContext … 
> 
> Do you face this problem? I have not found related bug on FogBugz. 
> 
> Thanks,
> Juraj
> 
> Pharo4.0 (Moose image 5.1)
> Latest update: #40613
> 
>