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

Re: [Pharo-dev] Pillar book-skeleton and more

by Yuriy Tymchuk

On 12 May 2014, at 08:13, phil(a)highoctane.be wrote: > Ah, nice! Thank you! > > I got a couple warnings on compile > > Generating files for all chapters > The method AbstractFileReference>>ensureDeleted has been deprecated. > Use ensureDelete > > *** Warning: Deprecation: The method AbstractFileReference>>ensureDeleted has been deprecated. > Use ensureDelete > The method AbstractFileReference>>ensureDeleted has been deprecated. > Use ensureDelete > > *** Warning: Deprecation: The method AbstractFileReference>>ensureDeleted has been deprecated. > Use ensureDelete > The method AbstractFileReference>>ensureDeleted has been deprecated. > Use ensureDelete > > *** Warning: Deprecation: The method AbstractFileReference>>ensureDeleted has been deprecated. > Use ensureDelete > The method AbstractFileReference>>ensureDeleted has been deprecated. > Use ensureDelete > > *** Warning: Deprecation: The method AbstractFileReference>>ensureDeleted has been deprecated. > Use ensureDelete > Done We have to look at it. Looks like the pillar-side things. > > > For Linux (CentOS6 for me): > > A mention of installing texlive-latex would be nice so that we can get a PDF. > > yum install texlive-latex > > or (to be confirmed by ubuntu users): > > apt-get install texlive-latex > > Once done, it works perfectly. We have to improve the script over time. Also itâs you are right that the command verses between distros. Anyway maybe we should put some notice. > > > For the Vim editor, I had to add a line matching .pillar files as the current setup from Damien is mapping .pier I think this can be requested at his repo :) > > So in: ftdetect/pier.vim > > duplicate the line and add a .pillar extension as well. > > autocmd! BufNewFile,BufRead *.pier setfiletype pier > autocmd! BufNewFile,BufRead *.pillar setfiletype pier > > > One less excuse not to write something nowâ¦ > > Phil > > > > > > > > > > > > > On Mon, May 12, 2014 at 7:38 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > 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

Re: [Pharo-dev] [Pharo-users] 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-dev] [Pharo-users] 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-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

Re: [Pharo-dev] developing games in Pharo

by Attila Magyar

Probably x86 windows tablets don't have the larges market share, but developing and running Pharo on them is equally easy than doing the same on a desktop computer. You can run the same x86 VM with JIT support and it runs fast. I tried PharoDroid before on an Android tablet but it was lot slower. Proper touch support is missing, but developing on a tablet with an external keyboard + mouse is possible. -- View this message in context: http://forum.world.st/developing-games-in-Pharo-tp4758592p4758725.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 12, 2014

Re: [Pharo-dev] Pillar book-skeleton and more

by phil＠highoctane.be

Ah, nice! I got a couple warnings on compile Generating files for all chapters The method AbstractFileReference>>ensureDeleted has been deprecated. Use ensureDelete *** Warning: Deprecation: The method AbstractFileReference>>ensureDeleted has been deprecated. Use ensureDelete The method AbstractFileReference>>ensureDeleted has been deprecated. Use ensureDelete *** Warning: Deprecation: The method AbstractFileReference>>ensureDeleted has been deprecated. Use ensureDelete The method AbstractFileReference>>ensureDeleted has been deprecated. Use ensureDelete *** Warning: Deprecation: The method AbstractFileReference>>ensureDeleted has been deprecated. Use ensureDelete The method AbstractFileReference>>ensureDeleted has been deprecated. Use ensureDelete *** Warning: Deprecation: The method AbstractFileReference>>ensureDeleted has been deprecated. Use ensureDelete Done For Linux (CentOS6 for me): A mention of installing texlive-latex would be nice so that we can get a PDF. yum install texlive-latex or (to be confirmed by ubuntu users): apt-get install texlive-latex Once done, it works perfectly. For the Vim editor, I had to add a line matching .pillar files as the current setup from Damien is mapping .pier So in: ftdetect/pier.vim duplicate the line and add a .pillar extension as well. autocmd! BufNewFile,BufRead *.pier setfiletype pier autocmd! BufNewFile,BufRead *.pillar setfiletype pier One less excuse not to write something now... Phil On Mon, May 12, 2014 at 7:38 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > 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

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

Re: [Pharo-dev] Load Zinc and some packages without UI

by Sebastian Sastre

awesome! thanks for that! On May 11, 2014, at 3:05 PM, Johan Brichau <johan(a)inceptive.be> wrote: > Hi Sebastian, > > Adding this around the load expression should make it work: > > [ ... ] on: MCMergeOrLoadWarning do: [ :ex | ex resume: true]. > > btw, this is the same problem that caused broken builds when I updated Grease #stable back in March > > Johan > > On 11 May 2014, at 19:55, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> Hi list and Sven :) >> >> Iâd like to load some additional packages about Zinc without human intervention >> >> If I use this: >> >> Gofer it >> smalltalkhubUser: 'Pharo' >> project: 'MetaRepoForPharo30'; >> package: 'ConfigurationOfZincHTTPComponents'; >> load. >> >> (Smalltalk at:#ConfigurationOfZincHTTPComponents) load. >> ((Smalltalk at:#ConfigurationOfZincHTTPComponents) project version: #stable) load: #('REST' 'SSO' 'WebSocket' 'Zodiac'). >> >> >> I do get an UI asking for merge or to confirm load >> >> What am I doing wrong to make it automation friendly? >> >> sebastian >> >> o/ >> >> >> >> >> > >

May 12, 2014

Re: [Pharo-dev] Roassal 3D empty windows

by Alexandre Bergel

Iâve just added a browser example, accessible from the Tools World menu. Cheers, Alexandre On May 11, 2014, at 10:20 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-03-31 9:56 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > Hi Alexandre, Ronie, igor > > it isn't solved yet. It works if I make the default extent > larger: > > As I described here and on the NBOpenGL Windows thread, > on my machine(s) (both with ATI Graphics) ,the framebuffer objects > (all/one?) does not update its internal buffer sizes after they are initilialized with the > default Morph extent 50@40. Therefore, the rendering happens > only in the upper left corner with extent 50@40. (and some rendering artifacts > in the remaining area. not rendering artifacts actually, looks like texture wrap clamp to edge. > Although I can not find a place where this texture wrap mode is set.) > > (on linux, phew, there are so many not working things, I don't know if it > is a driver issue: > hardcoded libpath, some distribution don't put the libGL.so under /usr/bin > missing type (something with GLXDisplay ?, I don't remember) > errors in some NB calls, > If I fix the first two issues it still does not work, because I don't know how > to handle the NB call errors.) > > Maybe it is easier to list OS and Hardware where R3D does work, than > to list the non working one. > > What OS and graphic cards do you use and test for NBOpenGL and R3D, mac os only? > > > > Nicolai > > > > > > > > > > 2014-03-30 22:07 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > > Is this problem been solved already? > > Alexandre > > > On Mar 17, 2014, at 7:35 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > As described in the "NBOpenGL on Windows" thread, I have a windows > > machine where NBOpenGL can not create frame buffer objects (driver issue maybe). > > > > But on another windows machine, there is no error but strange rendering results. > > > > On that machine, Roassals 3D IDE, still only shows empty windows. And other > > demos shows the same strange rendering (see screenshot, includes GL context driver info). > > > > > > (BTW, there is some class name missmatch in NBGLCurveRenderer in this NBOpenGL version. > > It referse to NBGLFragmentProgram although there is only a NBGLFragmentProgramARB class > > in the system). > > > > > > > > > > 2014-03-17 15:55 GMT+01:00 Ronie Salgado <roniesalg(a)gmail.com>: > > Hi Nicolai, > > > > What are your system specs?, specially your graphic card. > > Roassal3D requires a graphic card with at least OpenGL 2.0 support. Try updating your graphic drivers > > > > Greetings, > > Ronie > > > > > > 2014-03-17 11:03 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > > > > Ohâ¦ Have you tried to update Athens and NBOpenGL ? Maybe you are using an old version of them. > > Maybe an old version of OpenGL is installed on your Window? > > > > Ronie, any idea whatâs going on? > > > > Alexandre > > > > > > On Mar 17, 2014, at 10:55 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > > Thank you Alexandre, > > > this was what I tried under windows, (I wasn't sure if this is still the right way to do it, I > > > read it the Roassal3dTutorial.pdf). > > > But it doesn't work. Either I am getting empty windows or (with an other > > > NBOpenGL version) > > > Frame buffer is incomplete: GL_FRAMEBUFFER_UNSUPPORTED') > > > > > > I tried this once with linux too, and it didn't worked. But I am not sure how long ago :) > > > I'll try it again and report back. > > > > > > (Another note, after downloading the configuration, this: > > > (Smalltalk at: #ConfigurationOfRoassal3d) loadDevelopment > > > takes awfully long on windows (~ 5 min). > > > I am sure it was much faster on linux, any idea how that can be?) > > > > > > > > > > > > > > > > > > > > > 2014-03-17 14:34 GMT+01:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > > > Hi Nicolai, > > > > > > Roassal3d works well with the last Pharo 3.0. > > > You just need to execute the following incantation: > > > > > > -=-=-=-=-=-=-=-=-= > > > Gofer new smalltalkhubUser: 'ronsaldo' project: 'roassal3d'; package: 'ConfigurationOfRoassal3d'; load. (Smalltalk at: #ConfigurationOfRoassal3d) loadDevelopment > > > -=-=-=-=-=-=-=-=-= > > > > > > This does not work for you? > > > It works well on OSX and on Linux > > > > > > Alexandre > > > > > > > > > On Mar 15, 2014, at 10:52 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > > > > Hi, > > > > > > > > what could be the reason, that any Roassal3d example from the > > > > Roassal3DTutorial.pdf only shows white empty windows? > > > > > > > > I loaded ConfigurationOfRoassal3d-RonieSalgado.10 and > > > > (Smalltalk at: > > > > #ConfigurationOfRoassal3d) loadDevelopment > > > > > > > > Any ideas? > > > > > > > > > > > > regards > > > > Nicolai > > > > > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > <PharoScreenshot.png> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > So, I finally solved this issue for me. Instead of making the initial framebuffer large enough, I > changed the code in NBGLFrameBuffer>>extent: > to reattach all attached Renderbuffers. ( I don't know if this is a driver issue or > if it is a failure in NBOpenGL) > > Again, someone can tell me where (OS, graphic-card) Roassal 3D runs out of the box? > > And even now, that I solved this issue and all(many) Roassal examples are working, > The R 3D IDE still only shows a black screen. And I still don't know what this is supposed > to be, any tutorial screenshot or video, showing what R3D IDE is? > > > Nicolai > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 11, 2014

Re: [Pharo-dev] Roassal 3D empty windows

by Alexandre Bergel

Hi Nicolai, Thanks for coming back to us. Your patience is crucial for us :-) > Again, someone can tell me where (OS, graphic-card) Roassal 3D runs out of the box? I have just taken a Moose image, loading Roassal3d using the Configuration browser. I then manually updated the NBOpenGL by hand (I have produced a new configuration but I do not have the right to write in the repository). > And even now, that I solved this issue and all(many) Roassal examples are working, > The R 3D IDE still only shows a black screen. And I still don't know what this is supposed > to be, any tutorial screenshot or video, showing what R3D IDE is? R3D IDE is just a small and quick experiment. Nothing fancy behind (else we would have advertise it :-) You can use it the following: - Open the Roassal3D IDE - Open a System browser and compile method methods, create classes You should see some cubes in the IDE. Iâve just realized that moving from Roassal to Roassal2 has left some problems. I am working on them right nowâ¦ Again, thanks for keeping trying R3D. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 11, 2014