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

Re: [Pharo-project] Traits depending on RIng

by Mariano Martinez Peck

On Sat, May 5, 2012 at 5:40 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Thanks mariano. I love when you write your phd this is so boring that you > have to do something else :D > hehehehhehe 5 hours per day. That's my maximum hahaha > And this is great to have a real layered system. > Indeed. Before this change: 1) Traits were not working without Ring and therefore we needed to include Ring in PharoKernel 2) Ring was unloadable otherwise traits were broken now we can unload ring if we want and moreover, we do not need it in PharoKernel. So, yes, it was a good move. Thanks you for proposing the idea and thanks to Marcus and Guille that proposed to use CompiledMethod instead ;) > Stef > > > > > > > > On Sat, May 5, 2012 at 12:30 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > > > > > > On Sat, May 5, 2012 at 11:39 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > > Good idea guys. I am trying now... > > > > > > On Sat, May 5, 2012 at 9:43 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > > > > On May 4, 2012, at 11:46 PM, Guillermo Polito wrote: > > > > > > > > So...what do we do? we just accept the depedency? > > > > > > Why not use a CompiledMethod instead? More on, the > TraitMethodDescription already knows the selector, so storing only the > behaviors containing related methods should be enough... > > > > > > > Yes, the code is old from a time when CompiledMethod did not know the > class or selector. > > > > So this can be rewritten to just use compiledMethod. > > > > So guys. I did an experiment with this. So I used a CompiledMethod > rather than a RGMethodDefinition. I did a changeset (not sure if Monticello > can handle these changes) just to have another one eye's on it. Basically, > I needed to change the senders of #locatedMethods because now such method > answers a collection of CompiledMethod rather than RGMethodDefinition. > > > > I tested with Fuel (fuel has lots of tests regarding traits) and even > building PharoCore from PharoKernel without Ring in kernel and putting all > packags in the same bundle. (it works!!!). > > However, the traits tests from Pharo are completly broken and it is > impossible to do something. You run one test and you got 30 debuggers. It > is impossible to test. > > > > So, if someone can take a look, I really appreciate it. > > http://code.google.com/p/pharo/issues/detail?id=5815 > > > > wait. I found a problem... I will upload a new version soon. > > > > > > > > > > Thanks > > > > > > > > Marcus > > > > > > -- > > Marcus Denker -- http://marcusdenker.de > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

May 5, 2012

Re: [Pharo-project] Can OSProcess functionality be implemented using FFI instead of plugin?

by Eliot Miranda

On Sat, May 5, 2012 at 9:00 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Fri, May 4, 2012 at 6:23 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Hi, David, all >> >> i just want to know, if we can use FFI calls, for implementing an >> OSProcessPlugin functionality (or at least most of it). >> and if there parts which is hard to implement, i would like to know >> what and why. >> > > Once we have the threaded FFI and the threaded VM then yes, because one > can block one thread in a read without blocking the entire VM. But without > the threaded VM one needs asynchronous i/o. > But it can still be convenient to have a forkAndExec combined primitive to avoid the complications of having the system run hile forked (two processes accessing the same screen and changes files, so that if there's an error in the forked child it will collide with the parent when reporting its error). > > >> If you want to ask, why one would want to do this.. the answer is simple: >> we stated previously, that we want to reduce the VM complexity by >> implementing things at language side, when it possible, >> leaving only key parts to VM. >> This is the main reason why i consider implementing OSProcess using >> purely FFI, not because of quality of OSProcessPlugin >> implementation etc. >> >> -- >> Best regards, >> Igor Stasenko. >> >> > > > -- > best, > Eliot > > -- best, Eliot

May 5, 2012

Re: [Pharo-project] Can OSProcess functionality be implemented using FFI instead of plugin?

by Eliot Miranda

On Fri, May 4, 2012 at 6:23 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hi, David, all > > i just want to know, if we can use FFI calls, for implementing an > OSProcessPlugin functionality (or at least most of it). > and if there parts which is hard to implement, i would like to know > what and why. > Once we have the threaded FFI and the threaded VM then yes, because one can block one thread in a read without blocking the entire VM. But without the threaded VM one needs asynchronous i/o. > If you want to ask, why one would want to do this.. the answer is simple: > we stated previously, that we want to reduce the VM complexity by > implementing things at language side, when it possible, > leaving only key parts to VM. > This is the main reason why i consider implementing OSProcess using > purely FFI, not because of quality of OSProcessPlugin > implementation etc. > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

May 5, 2012

Re: [Pharo-project] Traits depending on RIng

by StÃ©phane Ducasse

Thanks mariano. I love when you write your phd this is so boring that you have to do something else :D And this is great to have a real layered system. Stef > > > On Sat, May 5, 2012 at 12:30 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sat, May 5, 2012 at 11:39 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Good idea guys. I am trying now... > > > On Sat, May 5, 2012 at 9:43 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On May 4, 2012, at 11:46 PM, Guillermo Polito wrote: > > > > > So...what do we do? we just accept the depedency? > > > > Why not use a CompiledMethod instead? More on, the TraitMethodDescription already knows the selector, so storing only the behaviors containing related methods should be enough... > > > > Yes, the code is old from a time when CompiledMethod did not know the class or selector. > > So this can be rewritten to just use compiledMethod. > > So guys. I did an experiment with this. So I used a CompiledMethod rather than a RGMethodDefinition. I did a changeset (not sure if Monticello can handle these changes) just to have another one eye's on it. Basically, I needed to change the senders of #locatedMethods because now such method answers a collection of CompiledMethod rather than RGMethodDefinition. > > I tested with Fuel (fuel has lots of tests regarding traits) and even building PharoCore from PharoKernel without Ring in kernel and putting all packags in the same bundle. (it works!!!). > However, the traits tests from Pharo are completly broken and it is impossible to do something. You run one test and you got 30 debuggers. It is impossible to test. > > So, if someone can take a look, I really appreciate it. > http://code.google.com/p/pharo/issues/detail?id=5815 > > wait. I found a problem... I will upload a new version soon. > > > > > Thanks > > > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com >

May 5, 2012

Re: [Pharo-project] FileReference convenience

by StÃ©phane Ducasse

we should migrate the system to use it so that we can deprecate the old code. > Now that Filesystem is built-in, how about starting to add some convenience > methods, like this simple one... > > FileReference>>#fileIn > > FileStream fileIn: self fullName. > > -- > View this message in context: http://forum.world.st/FileReference-convenience-tp4609828.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 5, 2012

Re: [Pharo-project] Slint in Pharo 1.4 / Nautilus?

by StÃ©phane Ducasse

did you check the mail of simon allier? ConfigurationOfManifest... > Hi, > > I do not have a clue how to load Slint in Pharo 1.4. Is there something to use it with Nautilus (altough, I dont really need a GUI)? > > Cheers, > Francois >

May 5, 2012

Re: [Pharo-project] Drawing speed for animations?

by Igor Stasenko

On 5 May 2012 09:39, Martin Drautzburg <Martin.Drautzburg(a)web.de> wrote: > On Saturday, 5. May 2012 02:38:11 Igor Stasenko wrote: >> On 5 May 2012 01:43, Martin Drautzburg <Martin.Drautzburg(a)web.de> wrote: >> > On Saturday, 5. May 2012 00:17:09 Igor Stasenko wrote: >> >> may i ask you, what is your plans? >> >> say, you want to implement a particle system which can be animated at >> >> decent frame rate, >> >> or something more complex? >> > >> > No much simpler. All I am doing is some sort of gantt chart. I thought >> > smoth- scrolling would be cool, so I implemented it. But it just doesn't >> > look as smooth as an iPad (but pretty smoth nontheless) >> >> but you can cheat. >> look at ipad/imac zooming interface.. when you zoom in, it doesn't >> redraws the whole >> desktop each frame. it just captures screenshoot and zooms that image >> instead (with nice filtering of course).. and only when you stop >> zooming, it redraws everything at new scale. > > Where would I have to look, when I want to do somehting like this? I had some > hope in CachingMorph and I replaced my smooth scrolling RectangleMorph with a > CachingMorph, but that froze everything, so it is probably not as simple as > that. i dont think there is something like that. what you need is to create a large Form and then draw your scene there. form := Form extent: ... depth:.. . canvas := form getCanvas. self drawFullSceneOn: canvas then you just use rendered result for drawing on screen: drawOn: canvas canvas drawImage: form at: self origin + scrollamount someething like that. > -- > Martin > -- Best regards, Igor Stasenko.

May 5, 2012

Re: [Pharo-project] [squeak-dev] Re: [ANN] STON - Smalltalk Object Notation

by Sven Van Caekenberghe

Hi Hannes, On 05 May 2012, at 11:53, H. Hirzel wrote: > Thank you Sven for your follow up of the recent JSON/STON/Tirade > discussion by providing an STON implementation for Squeak 4.3 and > working with Dale to get it to other Smalltalks (github). [1] > > I think your STON implementation will be very useful for my work. It > works fine in Squeak 4.3 updated to the latest change [2]. Thanks for the feedback and the encouragement. > There is a class STON used as a singleton. I assume this is the > equivalent of the JSON object in web browsers, right? I am afraid I am not familiar enough with how JSON is handled in Javascript/Webbrowsers, so I cannot compare. But the STON object in the current implementation is a class facade API to read/write to/from streams/strings while hiding the actual parser or writer classes. It is a central access point, but it is very thin: using STONReader or STONWriter directly is perfectly OK too. Maybe I should add some invocation examples to the paper to explain the API. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 5, 2012

Re: [Pharo-project] Questionn

by Ben Coman

Igor Stasenko wrote: > On 2 May 2012 19:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> First class instance variables will bring a lot to the system: >> foundation for a lot of innovation >> - relationships support >> - meta description. >> > > > > >> - bitfields description >> > > this one was always overrated, IMO. > unless you wanna parse the IP packet headers, where else you want to > play with bit fields, > and care how they fit in memory? :) > Industrial process control - where you have hundreds of physical digital inputs and outputs providing feedback from limit switches and driving control relays.

May 5, 2012

Re: [Pharo-project] Artefact - a PDF framework

by Olivier Auverlot

Sorry for the lag, I'm in holidays (off line and high priority for childs) ;-) Artefact is just a response at my needs. For my work, I need faster of a PDF library to generate letters and reports. I have used the Infinite Improbability Drive to build a thin library. In my mind, Artefact is not an ultimate response at each problem but an simple and extensible tool. If someone works on PDF4Smalltalk for Pharo, it's a good thing because I think that it will better to have differents solutions for differents problems. Olivier Le 2 mai 2012 Ã 16:27, Stephan Eggermont a Ã©crit : > Hi Olivier, > > I've taken a look at the state of Artefact. Don't you think it would be much less work > to port Christian Haider's work to Pharo? The namespace extensions to ring should > be helpful to make two-way changes from both the VW and Pharo side. > > Stephan Eggermont

May 5, 2012