- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Athens OpenGL backend - what does it mean?

by dimitris chloupis

"eye candy" wise this is exactly the focus of my Ephestos project , Morpheas section. A custom gui , gui designers for easy creating of GUIs by the user and additional moprh widget with customized look including eye candy. I can't make any promises, as I have no clue what kind of obstacles and technical limitations I am going to find in the process but I can tell you I am willing to invest years and if all goes well even decades of efforts since its an area that I love to code for. As a first part I am in the process of creating a tutorial generator which will be ProfStef on steroids for at first offering tutorial for Athens and later used for any kind of Pharo tutorial. I am also interested in helping Athens porting to OpenGL and generally using NBOpenGL as the next step for Morphic. Excitting stuff the only thing it worries me is the type of technical blocks / obstacles I may come across but trying is certainly well worths it. ________________________________ From: Sebastian Nozzi <sebnozzi(a)gmail.com> To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, 24 November 2012, 17:06 Subject: [Pharo-project] Athens OpenGL backend - what does it mean? Hello Pharo Devs, I am really excited about the direction Pharo is taking regarding many areas - one of them being the graphics. I played with Athens a bit and it's cool to see anti-aliased vectror graphics coming to Pharo. I keep reading about a possible OpenGL back-end in the future... what would this mean exactly? For years I have been "dreaming" about graphic-accelerated "eye-candy" effects inside of the Smalltalk environment. Like compiz-fusion effects in Linux, or Quartz-Extreme powerded in OS-X (ExposÃ©, etc.). Would this be possible with such a back-end? Or am I misinterpreting things? I'm not a graphic-dev expert. Best regards, Sebastian

Nov. 25, 2012

Re: [Pharo-project] Pharo 2.0 on Raspberry Pi ?

by Denis Kudriashov

2012/11/25 Sven Van Caekenberghe <sven(a)stfx.eu> > Denis, > > I just redownloaded the archive that I posted, and I was able to run from > the newly created directory. > I am afraid there is some binary incompatibility with your device. > Maybe you could try recompiling from the official linux vm archive ? > I will try it at future. (I am not friendly with C world) Thank's for help

Nov. 25, 2012

Re: [Pharo-project] NativeBoost callbacks - status?

by Igor Stasenko

On 25 November 2012 13:27, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > > > On Sat, Nov 24, 2012 at 3:39 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> okay, seems like i found why: >> >> NBExternalAddress>>ulongAt: zeroBasedOffset put: value >> "Store unsigned 64-bit integer into memory at (receiver's address + >> ZERO-based offset) using native byte order. >> Note, there is no range checking " >> >> It should use 32-bit values.. >> Callback code using ulongAt:put. to store single value at certain >> address in machine code. >> Since it stores 64-bit value instead of 32bit, it overrides the >> instructions which follow, and of course that leads to crash. >> >> Trait aliases.. is wrong: >> >> #longAt:->#nbInt64AtOffset:. #longAt:put:->#nbInt64AtOffset:put:. >> #ulongAt:->#nbUInt64AtOffset:. #ulongAt:put:->#nbUInt64AtOffset:put: >> >> >> another reason to get rid of confusion with C types.. >> > Yep indeed... that's the issue ... I have corrected it locally, but I cannot > commit it (it seems I'm not in the developers list anymore): > yeah.. squeaksource sometimes "forgets" some metadata, when it crashes.. i added you back. But if you just want to fix this, and nothing else, don't bother: i already committed the fix as well as a lot more code.. I want to release new version of config with new great stuff. :) > NBExternalHandle variableByteSubclass: #NBExternalAddress > uses: TNBMemoryAccessors @ {#byteAt:->#nbInt8AtOffset:. > #byteAt:put:->#nbInt8AtOffset:put:. #longAt:->#nbInt32AtOffset:. > #longAt:put:->#nbInt32AtOffset:put:. #ulongAt:->#nbUInt32AtOffset:. > #ulongAt:put:->#nbUInt32AtOffset:put:} > > Cheers, > Ciprian >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro -- Best regards, Igor Stasenko.

Nov. 25, 2012

Re: [Pharo-project] Pharo 2.0 on Raspberry Pi ?

by Sven Van Caekenberghe

Denis, I just redownloaded the archive that I posted, and I was able to run from the newly created directory. I am afraid there is some binary incompatibility with your device. Maybe you could try recompiling from the official linux vm archive ? Sven On 25 Nov 2012, at 09:28, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Besides, "ldd squeakvm" from squeak dir not see file. But ls -l show me squeakvm with full permissions > > 2012/11/25 Denis Kudriashov <dionisiydk(a)gmail.com> > Hello. > Thank's for share. > > But unfortunatelly I cant run squeakvm. I have error > -sh: ./squeakvm: not found > (same with full headless image script) > I extract tar to usr/lib and I can run hello.sh file with some echo from it. But squeakvm strangelly not work. > And I have other executalbe binaries which I can just copy to phone and run. > Google not help me yet > > Best regards, > Denis > > > 2012/11/24 Sven Van Caekenberghe <sven(a)stfx.eu> > Hi Denis, > > On 24 Nov 2012, at 11:25, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > Hello. > > > > Can you share prebuilt VM? > > I have linux mobile phone (meegoOS with ARMv7 processor). And I really want pharo on it. I try built VM by myself but without success. > > > > Best regards, > > Denis > > Here is a .tgz of the VM > > https://dl.dropbox.com/u/16235440/raspberrypi-squeak.tgz > > as well as some additional info about the executables > > pi@raspberrypi ~ $ file /usr/lib/squeak/4.4.7-2357/squeakvm > /usr/lib/squeak/4.4.7-2357/squeakvm: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xee98a23c74f457d15c4b70c8c21e640dd0b375d9, stripped > > pi@raspberrypi ~ $ file /usr/lib/squeak/4.4.7-2357/so.UUIDPlugin > /usr/lib/squeak/4.4.7-2357/so.UUIDPlugin: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xe3771585b163d3706ba159f7e024488615e56771, stripped > > pi@raspberrypi ~ $ ldd /usr/lib/squeak/4.4.7-2357/squeakvm > /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0x4031c000) > libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x40192000) > libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x40085000) > libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0x40001000) > libnsl.so.1 => /lib/arm-linux-gnueabihf/libnsl.so.1 (0x40090000) > libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x400e7000) > libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x40325000) > /lib/ld-linux-armhf.so.3 (0x400b6000) > libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x4010f000) > > > I hope your system is compatibleâ¦ > > Regards, > > Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Nov. 25, 2012

Re: [Pharo-project] NativeBoost callbacks - status?

by Ciprian Teodorov

On Sat, Nov 24, 2012 at 3:39 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > okay, seems like i found why: > > NBExternalAddress>>ulongAt: zeroBasedOffset put: value > "Store unsigned 64-bit integer into memory at (receiver's address + > ZERO-based offset) using native byte order. > Note, there is no range checking " > > It should use 32-bit values.. > Callback code using ulongAt:put. to store single value at certain > address in machine code. > Since it stores 64-bit value instead of 32bit, it overrides the > instructions which follow, and of course that leads to crash. > > Trait aliases.. is wrong: > > #longAt:->#nbInt64AtOffset:. #longAt:put:->#nbInt64AtOffset:put:. > #ulongAt:->#nbUInt64AtOffset:. #ulongAt:put:->#nbUInt64AtOffset:put: > > > another reason to get rid of confusion with C types.. > > Yep indeed... that's the issue ... I have corrected it locally, but I cannot commit it (it seems I'm not in the developers list anymore): NBExternalHandle variableByteSubclass: #NBExternalAddress uses: TNBMemoryAccessors @ {#byteAt:->#nbInt8AtOffset:. #byteAt:put:->#nbInt8AtOffset:put:. #longAt:->#nbInt32AtOffset:. #longAt:put:->#nbInt32AtOffset:put:. #ulongAt:->#nbUInt32AtOffset:. #ulongAt:put:->#nbUInt32AtOffset:put:} Cheers, Ciprian > > -- > Best regards, > Igor Stasenko. > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Nov. 25, 2012

Re: [Pharo-project] MongoTalk update

by Fernando Olivero

Hi, this seems to answer your question. http://articles.tulipemoutarde.be/embedded-document-with-voyage-in-mongodb Fernando On Sun, Nov 25, 2012 at 2:09 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 November 2012 14:06, Nicolas Petton <petton.nicolas(a)gmail.com> > wrote: > > > > Thanks Norbert! > > > > It's cool to know that you like it :) Together with Esteban's work on > > Voyage, it allows us to do extremely cool stuff with Mongo and Pharo. > > > > What I like with Voyage-Mongo + MongoQueries is that objects are > > persisted without any effort, it just works, and we can query Mongo > > collections like we would do with Smalltalk collections. > > > are you talking about serializing objects (or subgraphs) directly, and > storing them in mongo db ? > > > Nico > > > > Norbert Hartl <norbert(a)hartl.name> writes: > > > >> Hey Nico, > >> > >> I looked into your new stuff and I like it. Especially the MongoQueries > stuff is very simple and clean approach to do a small DSL. That boosts the > usability of MongoTalk extremely. Bravo! > >> > >> Norbert > >> > >> Am 19.11.2012 um 15:37 schrieb Nicolas Petton <petton.nicolas(a)gmail.com > >: > >> > >>> > >>> Hi guys, > >>> > >>> Lately I worked a bit on the Pharo Mongo driver for SmalltalkHub. I > made > >>> several changes (in the new version 1.4): > >>> > >>> The query API changed: > >>> > >>> - MongoCollection>>query: now takes a 1 arg block, improving the API > >>> quite a bit. > >>> > >>> Queries like: > >>> > >>> aCollection query: (aCollection query > >>> query: { 'foo' -> 'bar'} asDictionary; > >>> yourself) > >>> > >>> Is now written: > >>> > >>> aCollection query: [ :query | > >>> query where: { 'foo' -> 'bar'} ] > >>> > >>> Sending #asDictionary has also been made optional, the query builder > >>> will send #asMongoQuery to the query collection. > >>> > >>> > >>> The MongoQueries package: > >>> > >>> Version 1.4 comes with a new package MongoQueries, a small DSL allowing > >>> us to use traditional blocks instead of dictionaries to perform > >>> queries. This is optional and backward compatible. > >>> > >>> Queries like: > >>> > >>> aCollection select: { '$or' -> { 'name' -> 'foo'. 'age' -> { '$gt' -> > 23 } > >>> asDictionary } asDictionary } asDictionary > >>> > >>> can be expressed: > >>> > >>> aCollection select: [ :each | (each name = 'foo') | (each age > 23) ] > >>> > >>> The MongoQueries package should support the entire mongo query language > >>> (including nested queries), and comes with unit tests. > >>> > >>> Nico > >>> > >> > >> > > > > -- > > Nicolas Petton > > http://nicolas-petton.fr > > > > > > -- > Best regards, > Igor Stasenko. > >

Nov. 25, 2012

Re: [Pharo-project] Athens OpenGL backend - what does it mean?

by Fernando Olivero

yes! But not only it would enable having multiple windows, because now we "downgrade" all the events to the minimum common denominator, and pass a "raw event" captured from each OS, from the vm to the image. would be nice to do some surgery on the vm, and cut the windowing management and raw event handling away. It belongs in the image, if it can be implemented using NB to the OS UI frameworks, or in a separate app. We just need a surgeon with the time and ability to do soâ¦.i've tried in the past and the related VM code was really hard to understand. Fernando pd: There were some discussion around this idea last year in the mailing list. On Sun, Nov 25, 2012 at 9:40 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Nov 24, 2012, at 5:19 PM, Sebastian Nozzi wrote: > > >> sure thing i want as many as we want. > > > > Excellent! > > > >> we need to change VM, to let image be in better control of host system > windows. > >> once we will have that, having multiple windows & effects will not > >> pose any problems anymore. :) > > > > Now when you say "host system windowS" you mean... that the plan is to > > have *many* host windows, not just one as is the case? :-O > > we would love that. > This is not because there is not something right now that this is > something we do not want. > We just try to make progress and not open too many projects. Finishing is > important to pass to the > next level. > > > > > > I was just referring to the Morphic class SystemWindow... > > > > Cheers, > > > > Sebastian > > > > >

Nov. 25, 2012

[Pharo-project] dumpfs - inspecting floating point numbers

by Sven Van Caekenberghe

Hi, I just came across this: http://blog.reverberate.org/2012/11/dumpfp-tool-to-inspect-floating-point.h… and I think it would be very cool to have something like that for Smalltalk, as a standard, builtin feature. It would fit the Smalltalk philosphy of understandability very well. Nicolas ? ;-) Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Nov. 25, 2012

Re: [Pharo-project] [ann] glamorous debugger (alpha)

by StÃ©phane Ducasse

No so far only for 1.4 Stef On Nov 25, 2012, at 1:48 AM, Camillo Bruni wrote: >> >> If you are interested in playing with it, you can either find it in the Moose image, or you can load it in Pharo 1.4 via: >> Gofer new >> squeaksource: 'glamoroust'; >> package: 'ConfigurationOfGlamoroust'; >> load. >> (Smalltalk at: #ConfigurationOfGlamoroust) loadDevelopment > > is it supposed to load under 2.0? I get an issue with ConfigurationOfRPackage..

Nov. 25, 2012

Re: [Pharo-project] [Ann] 4.7 beta

by StÃ©phane Ducasse

On Nov 25, 2012, at 12:47 AM, Tudor Girba wrote: > Hi, > > As a result of the successful Moose Dojo that took place on November 15-16, Moose 4.7 entered the beta state. Some of the outcomes of the Dojo are: > - Cleaned a couple of hundred obsolete FAMIX navigation methods (by Robert and Nicolas) > - Fixed the major bug when editing code (by Andrei and Stephan) > - Fixed several other Glamour bugs (by Erwann) > - Worked on improving the PPAllParsersBrowser (by Jan) > - Got the GTDebugger to start to work with Bifrost (by Jorge and Andrei) I will extract the GDTDebugger model to push it into Pharo2.0. > - Got Reloader almost ready to work with Metacello and produce a reloadable version of the complete Moose (by Stephane and me). I will send more information to dale and I hope to get some time to work on it this week. Stef > > The 6 remaining issues are listed on the issue tracker: > http://code.google.com/p/moose-technology/issues/list?q=milestone%3D4.7 > > Of these, the most important are: > - http://code.google.com/p/moose-technology/issues/detail?id=869 (an unfortunate side effect of getting the code editing fast) > - http://code.google.com/p/moose-technology/issues/detail?id=865 (we need to find the way to get the proper loading order of all packages) > > Anyone want to join efforts on these? > > Ideally, we should release somewhere at the beginning of December. Afterwards, we move to Pharo 2.0. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > >

Nov. 25, 2012