- Pharo-users - lists.pharo.org

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

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

by Sabine KnÃ¶fel

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? Regards Sabine 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

Pillar book-skeleton and more

by Yuriy Tymchuk

Dear everyone, Iâm happy to announce about the Pillar book-skeleton project https://github.com/pillar-markup/book-skeleton, which is essentially a generalised starting point for writing books in Pillar. Pharo for the Enterprise and Updated Pharo by Example are using it now. If you have any suggestions, please contribute, or open issues. Together with that weâve created the GitHub organisation named Pillar-markup https://github.com/pillar-markup, which contains pillar-related projects like editor mods and documentation. If you have any Pillar related projectâs we will be happy to add you and the projects to the organisation. Have a nice week. Uko

May 12, 2014

Domaintalk - PDF Files

by Bob Williams

I decided to rewrite the Domaintalk proposal and the develop a Math Domain document. To do it correctly I had to use LaTeX which I have not used in decades. But it was worth the effort because it gave me more ideas about how to implement the Math Domain and it produces PDF files. I do not want to clutter this email area, nor your in baskets, so those that would like to see the document and provide comments which I welcome and need. Please reply to email account and I will send you a return email with three attachments: Domaintalk.pdf, MathDomainSpec.pdf and Mapping to Smalltalk Code.htm. bw

May 11, 2014

Re: [Pharo-users] Some code to share - Twitter access

by Paul DeBruicker

I think I have a use for it. Will you please post it to smalltalkhub or whereever you prefer? Thanks Paul Arturo Zambrano wrote > Hi All, > I have some code that allows to access Twitter data using its REST API > and the Streaming API (thanks Sven for helping me in > It is rudimentary and needs more work, but it is useful for what I'm > doing > as a hobby in: http://www.tweetreport.com.ar/ > > I would like to share it but it is still mixed with some other code of my > Twitter toy (thanks Alex , Pablo and all the Roassal team). > So, if there is people interested in this code, I will separate and > publish it. > > I just need to know if someone wants it to play, to avoid useless work. > > Best regards > art -- View this message in context: http://forum.world.st/Some-code-to-share-Twitter-access-tp4757068p4758680.h… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 11, 2014

Re: [Pharo-users] compiling Pillar files locally (for LaserGame book)

by Ben Coman

May 11, 2014

Re: [Pharo-users] Pharo3, what refactoring in morph mouse event?

by Hilaire Fernandes

Indeed, I tracked the changes done to Morph and PasteUpMorph since last September and I did not see any possible related changes. Now I should look at the StandardWindow as the DrGeo canvas is a pasteupmoprh plugged in a StandardWindow. Thanks Hilaire Le 11/05/2014 09:26, stepharo a Ã©crit : > Hi Hilaire >> Hi, >> >> With Pharo3, each time I click and drag in the DrGeo canvas I have a >> drag event of the surrounding DrGeo window. > > Do you have an image that we can have a look? > >> >> The mouse events doe not reach anymore the canvas as it should be >> (captured with usuale. >> >> Is it possible to know the refactoring in the mouse event and related >> departments. > Not easily even if we did not specifically worked on that area. >> >> Thanks >> >> Hilaire >> > > > -- Dr. Geo http://drgeo.eu

May 11, 2014

Re: [Pharo-users] Creating a subclass from nautilus/Pharo3

by Hilaire Fernandes

Please do so and tell me if I need to record the case in the bug tracker. Regarding Nautilus, it is worth the effort *TWO* people sit down side by side and redesign the menus hierarchy. Hilaire Le 11/05/2014 09:28, stepharo a Ã©crit : > With me it works. > So I will retry in the latest 3.0 -- Dr. Geo http://drgeo.eu

May 11, 2014