May 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Problem learning about Magritte

by stepharo

On 13/5/14 01:34, Esteban A. Maringolo wrote: > 2014-05-12 20:21 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > >> A faster way to start can be to use one of the images from >> https://ci.inria.fr/pharo-contribution/ >> Pier, QCMagritte and Forum all come with both Magritte and Seaside >> preloaded. > I don't like this "faster way" of prebuilt images. > Makes me think of seeds for forked branches. > Unless something is wrong with the package system, I would encourage > its use, even if it takes long. why? you can just read the configuration of the jenkins job and you know how to build it. The difference is that with the jenkins job we are SURE that the script to load works. Stef > > Regards, > > Esteban A. Maringolo > >

May 13, 2014

Re: [Pharo-users] Problem learning about Magritte

by stepharo

On 13/5/14 00:50, PBK Research wrote: > Hello > Sorry if this is the wrong place to ask this. I am trying to > understand how Magritte works, initially by following the first > example in Ch. 26.2 of the Seaside book. I have started with a fresh > download of Pharo 3.0, and I have installed Magritte 3 and Seaside 3. > I realise that the Seaside book example is based on Magritte 2, so I > have made necessary changes to the example code (descriptions are on > the instance side, insert <magritteDescription> pragmas, change > #description to #magritteDescription). All works well up to the point > where I try to generate the Seaside editor. This fails because the code: > Address example1 asComponent > produces a 'does not understand' message for #asComponent. I have not > been able to work through all of Seaside to see where this method is > defined, and I am at a bit of a loss. I know this is rather > elementary, but could someone give me a pointer? > Also, if Magritte 3 is now the norm, will the Seaside book examples be > updated to reflect this? They should but only I - reverse engineer Magritte 3 - get the time to do it I was planning to write an independent Chapter on Magrritte 3 but I got the same limits. So if somebody knowlegeable wants to start writing two/three blog posts we could turn it into a book chapter. > Thanks in advance for any help > Peter Kenny

May 13, 2014

Re: [Pharo-users] Problem learning about Magritte

by Esteban A. Maringolo

2014-05-12 20:47 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > Esteban wrote: >>I don't like this "faster way" of prebuilt images. >>Makes me think of seeds for forked branches. >>Unless something is wrong with the package system, I would encourage >>its use, even if it takes long. > > I strongly encourage the use of ci images. And of course you should > add your own, once you've decided what packages you need. > The main advantage is that it provides feedback to the core pharo > development on changes. I'm totally in about CI images for testing purposes, but not for distribution. Maybe it's a matter of personal taste. Esteban A. Maringolo ps: sorry for the off topic

May 12, 2014

Re: [Pharo-users] Problem learning about Magritte

by Esteban A. Maringolo

2014-05-12 20:47 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > Esteban wrote: >>I don't like this "faster way" of prebuilt images. >>Makes me think of seeds for forked branches. >>Unless something is wrong with the package system, I would encourage >>its use, even if it takes long. > > I strongly encourage the use of ci images. And of course you should > add your own, once you've decided what packages you need. > The main advantage is that it provides feedback to the core pharo > development on changes.

May 12, 2014

Re: [Pharo-users] Problem learning about Magritte

by Stephan Eggermont

Esteban wrote: >I don't like this "faster way" of prebuilt images. >Makes me think of seeds for forked branches. >Unless something is wrong with the package system, I would encourage >its use, even if it takes long. I strongly encourage the use of ci images. And of course you should add your own, once you've decided what packages you need. The main advantage is that it provides feedback to the core pharo development on changes. Stephan

May 12, 2014

Re: [Pharo-users] Problem learning about Magritte

by Esteban A. Maringolo

2014-05-12 20:21 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > A faster way to start can be to use one of the images from > https://ci.inria.fr/pharo-contribution/ > Pier, QCMagritte and Forum all come with both Magritte and Seaside > preloaded. I don't like this "faster way" of prebuilt images. Makes me think of seeds for forked branches. Unless something is wrong with the package system, I would encourage its use, even if it takes long. Regards, Esteban A. Maringolo

May 12, 2014

Re: [Pharo-users] Problem learning about Magritte

by Stephan Eggermont

Hi Peter That sounds like you have independently installed Seaside and Magritte. You might miss the part connecting them together. Seaside can be used without Magritte, and Magritte without Seaside. That happens if you just install stable Seaside and stable Magritte from the configuration browser. Can you check if you have Magritte-Seaside loaded? That is in the Seaside group of Magritte. If not, you need the other option in the configuration browser, just loading the configuration of Magritte3. Then in a workspace, do-it (ConfigurationOfMagritte3 project version: #stable) load: 'Seaside'. A faster way to start can be to use one of the images from https://ci.inria.fr/pharo-contribution/ Pier, QCMagritte and Forum all come with both Magritte and Seaside preloaded. Stephan

May 12, 2014

Problem learning about Magritte

by PBK Research

Hello Sorry if this is the wrong place to ask this. I am trying to understand how Magritte works, initially by following the first example in Ch. 26.2 of the Seaside book. I have started with a fresh download of Pharo 3.0, and I have installed Magritte 3 and Seaside 3. I realise that the Seaside book example is based on Magritte 2, so I have made necessary changes to the example code (descriptions are on the instance side, insert <magritteDescription> pragmas, change #description to #magritteDescription). All works well up to the point where I try to generate the Seaside editor. This fails because the code: Address example1 asComponent produces a 'does not understand' message for #asComponent. I have not been able to work through all of Seaside to see where this method is defined, and I am at a bit of a loss. I know this is rather elementary, but could someone give me a pointer? Also, if Magritte 3 is now the norm, will the Seaside book examples be updated to reflect this? Thanks in advance for any help Peter Kenny

May 12, 2014

Re: [Pharo-users] [Pharo-dev] Changed semantics for mongo ObjectID

by Sabine KnÃ¶fel

Thanks, Norbert! On Mon, May 12, 2014 at 11:38 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 12.05.2014 um 10:46 schrieb Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com>: > > Hi Norbert, > > what about objects which have been written to mongo with the old version > and will be read with the new version. Can they be read/found with the new > version? Or is there a migration needed? > > > Iâd say it should be safe just to upgrade the code. The exisiting ids > wonât change because encoding and decoding are always fully reversible. > Meaning regardless of the encoding scheme the ids are the same in the > database after being read and written. The only thing changes is the value > in the OID object in your image. There are two ways where this can fail. > Either you monkey with id values inside your code. Or you use manual > references to objects where the referenced id is not written as OID. > Everything else should be the same with the old and the new code. > In the meantime I even changed the generation of the id value to reflect > the mongo spec. Now the values should be comparable to what other drivers > (including mongo shell) are generating. This also means you can now ask > your ObjectId about its timestamp. Which of course gives you non-sense with > ids generated prior to the code update.. > > Norbert > > > > On Thu, May 8, 2014 at 11:30 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I needed to change the way ObjectIds are read from and written to BSON. >> BSON is a format that encodes its byte contents little endian. In mongo >> database the format of ObjectIds is different. The way an ObjectId is >> encoded is big endian. You can see this if you compare the outputs for an >> object when read from mongo shell and from pharo. The ids wonât match. >> >> If you do ânormalâ stuff with mongo it is unlikely you have noticed the >> effect. An OID is read the wrong way but also written the wrong way which >> makes it right again from the mongo database perspective. But it wonât work >> if you use a mixed query setting. Meaning reading an OID and requesting the >> database using javascript expression. This will fail. >> >> Iâm writing this because Iâm not sure the change can break existing >> software. The change is not included in the stable version, yet. If you >> want to test then load #bleedingEdge and report any problem that might >> occur. I will use the new behaviour and will take the freedom to make it >> stable if it works for some time. >> >> FYI, >> >> Norbert >> >> >> > >

May 12, 2014

Re: [Pharo-users] [Pharo-dev] Changed semantics for mongo ObjectID

by Norbert Hartl

Am 12.05.2014 um 10:46 schrieb Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com>: > Hi Norbert, > > what about objects which have been written to mongo with the old version and will be read with the new version. Can they be read/found with the new version? Or is there a migration needed? Iâd say it should be safe just to upgrade the code. The exisiting ids wonât change because encoding and decoding are always fully reversible. Meaning regardless of the encoding scheme the ids are the same in the database after being read and written. The only thing changes is the value in the OID object in your image. There are two ways where this can fail. Either you monkey with id values inside your code. Or you use manual references to objects where the referenced id is not written as OID. Everything else should be the same with the old and the new code. In the meantime I even changed the generation of the id value to reflect the mongo spec. Now the values should be comparable to what other drivers (including mongo shell) are generating. This also means you can now ask your ObjectId about its timestamp. Which of course gives you non-sense with ids generated prior to the code update.. Norbert > > > On Thu, May 8, 2014 at 11:30 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > I needed to change the way ObjectIds are read from and written to BSON. BSON is a format that encodes its byte contents little endian. In mongo database the format of ObjectIds is different. The way an ObjectId is encoded is big endian. You can see this if you compare the outputs for an object when read from mongo shell and from pharo. The ids wonât match. > > If you do ânormalâ stuff with mongo it is unlikely you have noticed the effect. An OID is read the wrong way but also written the wrong way which makes it right again from the mongo database perspective. But it wonât work if you use a mixed query setting. Meaning reading an OID and requesting the database using javascript expression. This will fail. > > Iâm writing this because Iâm not sure the change can break existing software. The change is not included in the stable version, yet. If you want to test then load #bleedingEdge and report any problem that might occur. I will use the new behaviour and will take the freedom to make it stable if it works for some time. > > FYI, > > Norbert > > >

May 12, 2014