- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Sugar Theme

by Hilaire Fernandes

Hey, thanks for the screenshot. Yes, this is still work in progress. By the way, do not hesitate to contribute any bits of improvements, the Monticello repository is wide open. For Surgar theme we should get rid of the shaded menu anyway. Several things need to be done. Some need internal change in Polymorph, for example to get rid of the arrow in the slider (you have noted the small round black shapes in place of the arrows in the slider, we should get rid of that ones, but Gary need to change a bit Polymorph to be able to do that). Oh, I should add a link of the Sugar UI guide in the Squeaksouce wiki. Hilaire HernÃ¡n Morales Durand a Ã©crit : > Hello Hilaire, > Nice theme, one little thing is happening in the contextual menu, > some items related with refactoring operations are unreadable, please > see the attachement to see what I mean.

April 3, 2010

Re: [Pharo-project] Sugar Theme

by Michael Rueger

On 4/2/2010 11:36 PM, Hilaire Fernandes wrote: > Hello, > > I have designed a first -- not finished yet -- Sugar theme for Polymorph Nice! We did a Sugar like theme for Sophie back then, might be worth checking in the css and artwork if anything could be reused for extending/fine-tuning your theme. Michael

April 3, 2010

Re: [Pharo-project] [FFI] ExternalStructure ownership (or not) of memory

by Andreas Raab

On 4/2/2010 8:37 PM, Schwab,Wilhelm K wrote: > Andreas, > > So ExternalStructure>>free is not invoked by default? Sady to say, I never even considered that possibility. It's not. Memory is cheap :-) Cheers, - Andreas > -----Original Message----- > From: pharo-project-bounces-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0(a)public.gmane.org [mailto:pharo-project-bounces-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0@public.gmane.org] On Behalf Of Andreas Raab > Sent: Friday, April 02, 2010 8:24 PM > To: The general-purpose Squeak developers list > Cc: Pharo-project-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0(a)public.gmane.org > Subject: Re: [Pharo-project] [FFI] ExternalStructure ownership (or not) of memory > > I would suggest that you only register a finalizer for objects where you > *do* have responsibility to reclaim them. There are no implicit finalizers registered for any subclasses of ExternalObject by default - the only thing that happens is that all handles are cleared when the image is restarted. > > Cheers, > - Andreas > > On 4/2/2010 5:17 PM, Schwab,Wilhelm K wrote: >> Hello all, >> >> Suppose I have a pointer to a structure and I do or do not have the responsibility of reclaiming the memory when a corresponding ExternalStructure sub-instance is finalized. How do I distinguish the two cases? One idea I had is to explicitly set the handle to nil if I do not own the memory, but (please correct me if I'm wrong), I can't do that while I'm still using the instance because it will presumably use the handle in accessing the fields, right? >> >> Looking at implementors of #isExternalAddress, maybe the idea is to use a byte array to make a copy of memory and an address to refer to it. >> >> What should I be asking? :) >> >> Bill >> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0(a)public.gmane.org > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 3, 2010

Re: [Pharo-project] [FFI] ExternalStructure ownership (or not) of memory

by Schwab,Wilhelm K

Andreas, So ExternalStructure>>free is not invoked by default? Sady to say, I never even considered that possibility. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Andreas Raab Sent: Friday, April 02, 2010 8:24 PM To: The general-purpose Squeak developers list Cc: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [FFI] ExternalStructure ownership (or not) of memory I would suggest that you only register a finalizer for objects where you *do* have responsibility to reclaim them. There are no implicit finalizers registered for any subclasses of ExternalObject by default - the only thing that happens is that all handles are cleared when the image is restarted. Cheers, - Andreas On 4/2/2010 5:17 PM, Schwab,Wilhelm K wrote: > Hello all, > > Suppose I have a pointer to a structure and I do or do not have the responsibility of reclaiming the memory when a corresponding ExternalStructure sub-instance is finalized. How do I distinguish the two cases? One idea I had is to explicitly set the handle to nil if I do not own the memory, but (please correct me if I'm wrong), I can't do that while I'm still using the instance because it will presumably use the handle in accessing the fields, right? > > Looking at implementors of #isExternalAddress, maybe the idea is to use a byte array to make a copy of memory and an address to refer to it. > > What should I be asking? :) > > Bill > > > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 3, 2010

[Pharo-project] A port of Pharo: Redline Smalltalk ...

by James Ladd

Hi Pharo-ites, I'm working on a port of Pharo to the Java Virtual Machine called Redline Smalltalk. (read more here: http://jamesladdcode.com/?p=323) I'm wanting to port every single class over time, but initially enough to get the compiler working and have a minimum runtime. Of the 1600+/- classes which are those necessary to make a small workable compiler and runtime environment? Rgs, James. _________________________________________________________________ Need a new place to live? Find it on Domain.com.au http://clk.atdmt.com/NMN/go/157631292/direct/01/

April 3, 2010

Re: [Pharo-project] [FFI] ExternalStructure ownership (or not) of memory

by Andreas Raab

I would suggest that you only register a finalizer for objects where you *do* have responsibility to reclaim them. There are no implicit finalizers registered for any subclasses of ExternalObject by default - the only thing that happens is that all handles are cleared when the image is restarted. Cheers, - Andreas On 4/2/2010 5:17 PM, Schwab,Wilhelm K wrote: > Hello all, > > Suppose I have a pointer to a structure and I do or do not have the responsibility of reclaiming the memory when a corresponding ExternalStructure sub-instance is finalized. How do I distinguish the two cases? One idea I had is to explicitly set the handle to nil if I do not own the memory, but (please correct me if I'm wrong), I can't do that while I'm still using the instance because it will presumably use the handle in accessing the fields, right? > > Looking at implementors of #isExternalAddress, maybe the idea is to use a byte array to make a copy of memory and an address to refer to it. > > What should I be asking? :) > > Bill > > >

April 3, 2010

Re: [Pharo-project] [squeak-dev] [FFI] ExternalStructure ownership (or not) of memory

by John M McIntosh

In dealing with the case where you have a Smalltalk object that is paired to a external object where you want to ensure both are freed (at some point). There are two choices (a) You store a reference (somehow) to the external object in your smalltalk object. This can be some sort of index number that the external logic understands how to turn that into a reference to the memory, or you store the bytes for a memory pointer in the smalltalk instance. Don't forget issues with 32 or 64 bit memory addresses. You then always send your smalltalk object a release method that ensures it's external memory usage is cleaned up, either by using the memory pointer bytes or the index handle, when you decide to dispose of the smalltalk object. The release method then talks to the external interface to dispose of the external memory. (b) Like above, but you use Finalization to ensure external memory gets cleaned up when the Smalltalk object goes away. On 2010-04-02, at 5:17 PM, Schwab,Wilhelm K wrote: > Hello all, > > Suppose I have a pointer to a structure and I do or do not have the responsibility of reclaiming the memory when a corresponding ExternalStructure sub-instance is finalized. How do I distinguish the two cases? One idea I had is to explicitly set the handle to nil if I do not own the memory, but (please correct me if I'm wrong), I can't do that while I'm still using the instance because it will presumably use the handle in accessing the fields, right? > > Looking at implementors of #isExternalAddress, maybe the idea is to use a byte array to make a copy of memory and an address to refer to it. > > What should I be asking? :) > > Bill > > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

April 3, 2010

[Pharo-project] [FFI] ExternalStructure ownership (or not) of memory

by Schwab,Wilhelm K

Hello all, Suppose I have a pointer to a structure and I do or do not have the responsibility of reclaiming the memory when a corresponding ExternalStructure sub-instance is finalized. How do I distinguish the two cases? One idea I had is to explicitly set the handle to nil if I do not own the memory, but (please correct me if I'm wrong), I can't do that while I'm still using the instance because it will presumably use the handle in accessing the fields, right? Looking at implementors of #isExternalAddress, maybe the idea is to use a byte array to make a copy of memory and an address to refer to it. What should I be asking? :) Bill

April 3, 2010

Re: [Pharo-project] Sugar Theme

by Alexandre Bergel

Thanks Hernan, Alexandre On 2 Apr 2010, at 18:41, HernÃ¡n Morales Durand wrote: > Hello Hilaire, > Nice theme, one little thing is happening in the contextual menu, > some items related with refactoring operations are unreadable, please > see the attachement to see what I mean. > Cheers, > > HernÃ¡n > > 2010/4/2 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: >> Hello, >> >> I have designed a first -- not finished yet -- Sugar theme for >> Polymorph >> >> http://www.squeaksource.com/SugarTheme.html >> >> It is only for pharo 1.1 (not sure it works as expected with 1.0) >> because >> polymorph was updated by Gary to help. >> >> With the support of Gary, I look at contributing more improvment in >> the >> future. >> >> Hilaire >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > <Theme1.jpg>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 3, 2010

Re: [Pharo-project] Sugar Theme

by HernÃ¡n Morales Durand

Hello Hilaire, Nice theme, one little thing is happening in the contextual menu, some items related with refactoring operations are unreadable, please see the attachement to see what I mean. Cheers, HernÃ¡n 2010/4/2 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Hello, > > I have designed a first -- not finished yet -- Sugar theme for Polymorph > > http://www.squeaksource.com/SugarTheme.html > > It is only for pharo 1.1 (not sure it works as expected with 1.0) because > polymorph was updated by Gary to help. > > With the support of Gary, I look at contributing more improvment in the > future. > > Hilaire > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 3, 2010