- Pharo-dev - lists.pharo.org

Re: [Pharo-project] NB FileSystem Primitives Speedup

by Nicolas Cellier

2012/6/3 Igor Stasenko <siguctua(a)gmail.com>: > On 2 June 2012 18:42, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > ... >> >> Ouch, Igor, you gonna give us a headache. >> That's exatly the kind of niceties that makes FFI impracticle without >> a pre-processor, remember our discussion? >> > > That kind of niceties is a poor man's meta programming. > I don't see it as an argument against FFI. For me it is a clear > argument against system design. > > Because look.. most of the times you don't care what happens under the hood of > your sport car.. until it stops working, or no longer meets your demands. > From position of consumer , it is clear what you do next - you go to > market and buy a new one, > or give it to engineers who can fix it. > So, either there is someone who can produce better cars (engineers), > or someone who can fix > your car (engineers). But if there nobody left, and only consumers > around, then you are in trouble. > > And FFI actually points to that trouble: you cannot communicate with > system without having > a highly sophisticated compiler and preprocessor and also without > knowledge about which bells you should ring and what whistles you > should whistle.. this is road to nowhere. > > This is clearly not FFI's fault. It is fault of system design. > For example, look at config.h file, which produced by autoconfig > utility.. can you tell me, what all those flags controlling? Ok, name > me the purpose of half of them.. Can you? > And then tell me, how you can write a "highly portable" C software and > guarantee that all those bells and whistles are correctly arranged? > Sure, I don't blame FFI for being mud, just for exposing such mud. As I told you, I doubt I'd like it to be mirrored in image. The mud is everywhere, and there ain't much we can do. So how are we supposed to fix this? Throw away linux/FreeBSD/MacOS/WinXX and start an OS from scratch? Fight with more mud crystallised in hardware with SqueakNOS? This purpose of FFI is to open the gates to the external world, not to increase our autism. There is a solution in such cases: we can wrap mud in a nice packet by writing an interface library that uses highly sophisticated compiler and preprocessor, advanced knowledge of C code hackers, and community support for building various distributions (youpi with autoconf Cmake and the like)... It's a bit simpler than writing a plugin or VM code because no knowledge of Smalltalk/VMMaker/slang is required. But, not very much different at the end. Nicolas > From position of an engineer it is wrong to be on the side of > consumers (i don't care, it is something under the hood of my car, > which makes it run). > And for sure, nobody cares about insignificant little fly such as Cog > VM, except from few of us. > So, you have to go and open a hood of a car and remove a rotten cats & > rats from there, > this is how you can move to better future. Otherwise at some point, > cars will stop working, > planes will stop flying, computers will stop working, because nobody > will be left who would > understand how to make or fix them. > > So, this is a right question, posed by Stephane: how we can make sure > that we will be able to > improve system in future, once its creators are gone, and nobody can > understand it anymore? > Only by simplifying and cleaning all layers of a system and without > relying on good Santa, which will come one day and clean this mess for > us. > > -- > Best regards, > Igor Stasenko. > Depends on

June 2, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by Igor Stasenko

On 2 June 2012 18:42, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: ... > > Ouch, Igor, you gonna give us a headache. > That's exatly the kind of niceties that makes FFI impracticle without > a pre-processor, remember our discussion? > That kind of niceties is a poor man's meta programming. I don't see it as an argument against FFI. For me it is a clear argument against system design. Because look.. most of the times you don't care what happens under the hood of your sport car.. until it stops working, or no longer meets your demands. >From position of consumer , it is clear what you do next - you go to market and buy a new one, or give it to engineers who can fix it. So, either there is someone who can produce better cars (engineers), or someone who can fix your car (engineers). But if there nobody left, and only consumers around, then you are in trouble. And FFI actually points to that trouble: you cannot communicate with system without having a highly sophisticated compiler and preprocessor and also without knowledge about which bells you should ring and what whistles you should whistle.. this is road to nowhere. This is clearly not FFI's fault. It is fault of system design. For example, look at config.h file, which produced by autoconfig utility.. can you tell me, what all those flags controlling? Ok, name me the purpose of half of them.. Can you? And then tell me, how you can write a "highly portable" C software and guarantee that all those bells and whistles are correctly arranged? >From position of an engineer it is wrong to be on the side of consumers (i don't care, it is something under the hood of my car, which makes it run). And for sure, nobody cares about insignificant little fly such as Cog VM, except from few of us. So, you have to go and open a hood of a car and remove a rotten cats & rats from there, this is how you can move to better future. Otherwise at some point, cars will stop working, planes will stop flying, computers will stop working, because nobody will be left who would understand how to make or fix them. So, this is a right question, posed by Stephane: how we can make sure that we will be able to improve system in future, once its creators are gone, and nobody can understand it anymore? Only by simplifying and cleaning all layers of a system and without relying on good Santa, which will come one day and clean this mess for us. -- Best regards, Igor Stasenko.

June 2, 2012

[Pharo-project] Log fwk

by Santiago Bragagnolo

i'm forking the thread to open it for feedback. (Sorry for the spam repeating my self, but gmail is working funny :S) ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Hi all! Sorry for making you wait, here is the promised post about logger. http://concretetypeinference.blogspot.com.ar/2012/06/pharo-logger-aka-paul-…<http://concretetypeinference.blogspot.com.ar/2012/06/pharo-logger-aka-paul-…> Sorry for the awful text-format, blogger is really ugly. I'll be opening a wordpress blog and migrating all the posts the sooner as i can. Try to use it if you need a logger and please, send feedback! The needed code to addit to any project is really few, for an easy example, download the project and see at examples :).

June 2, 2012

Re: [Pharo-project] Log framework

by Santiago Bragagnolo

Hi all! Sorry for making you wait, here is the promised post about logger. http://concretetypeinference.blogspot.com.ar/2012/06/pharo-logger-aka-paul-… Sorry for the awful text-format, blogger is really ugly. I'll be opening a wordpress blog and migrating all the posts the sooner as i can. Try to use it if you need a logger and please, send feedback! The needed code to addit to any project is really few, for an easy example, download the project and see at examples :). Santiago. 2012/6/1 Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> > Ok > > I' think i just need to add test and then is already usable. ( If you > think i must add anything, just say it :)* * ) > > > About last changes and configuration: > > The last add is pragma support: We have 2 pragmas configuration: > > <logConfiguration> That indicates the class method* *related know how to > manage de log configuration > > There is support to usit this way: > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > configurationOfLog > <logConfiguration> > ^ [ > > :builder | > builder forClass:LogTestObject > useLevel:#info > showingLogAs: ('%pih | %tstmp | %tag #%class >> %selector > [%log]' asPatternFormatter) > into: Transcript asLogWriter > holdLogInstances:true. > ]. > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > and this way > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > configurationOfLog: builder > <logConfiguration> > > > builder forClass:LogTestObject > useLevel:#info > showingLogAs: ('%pih | %tstmp | %tag #%class >> %selector > [%log]' asPatternFormatter) > into: Transcript asLogWriter > holdLogInstances:true. > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > The other pragma is > <logConfigurationAs:#aSymbol > > > This pragma says 'hey, forme use the #aSymbol configuration!', such as > #default. > > then you can go to > > LogConfiguration >> configuration class method > > and add symbols with named configurations and relate with explicit classes > with a simple pragma :) > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > For other side, the manage of the 'if-the-class-has-not-configuration' is > the same, search for the package configuration (that should be added in > LogConfiguration >> configuration class method ), and if is not a package > configuration, then go for the #default configuration. > > > > Tomorrow ill be adding tests and making a post on my blog with all the > functionalities: > > Writers available (Memory, File, Stdout, Transcript, CompositeWriter) > Formatters available (Pattern based -the one of the sample- > SimpleFormatter and CustomFormatter) > Filters available (the one who says how to decides if the log must be > showed or just skiped -- CategoryFilter and LevelFilter. ) > Holder ( an object which stores LogEntity objects - an object very much > richier than the string stored for MemoryWriter) > > And ill add to the post how to write nice configurations with the existing > code and, of course, how to add functionality in the way i thought the > framework. > > > *Again, the idea of this framework is to be used for all and have just > one logger, so, please, if any one think i must add or change something, > share it here. And if any wants to get his hands on the code the same, just > say it. * > > > > > > > >

June 2, 2012

[Pharo-project] [update 2.0] #20106

by StÃ©phane Ducasse

20106 ----- Issue 6012: Fixing Trait test since the event notifier is not silent!!! http://code.google.com/p/pharo/issues/detail?id=6012 Stef

June 2, 2012

Re: [Pharo-project] graph of object references

by Tudor Girba

Thanks, I will give it a try. Cheers, Doru On 2 Jun 2012, at 22:14, Mariano Martinez Peck wrote: > > > On Sat, Jun 2, 2012 at 10:10 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I would need to debug memory leaks (maybe induced by announcements), and for that I am thinking to use a graph of object references. > > I guess this would be easily possible with Fuel. If I have an object, how would I go about doing this? > > Hi Doru. Maybe this helps: > > http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/… > > (look at the end) > > cheers > > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Don't give to get. Just give." > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

June 2, 2012

[Pharo-project] Pharo-2.0-Tests Â» 32,mac - Build # 109 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 2, 2012

[Pharo-project] Pharo-2.0-Tests Â» 32,linux - Build # 109 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 2, 2012

[Pharo-project] [update 2.0] #20105

by StÃ©phane Ducasse

20105 ----- Issue 6011: avoiding MCWorkingCopy allManagers expressions http://code.google.com/p/pharo/issues/detail?id=6011

June 2, 2012

Re: [Pharo-project] graph of object references

by Mariano Martinez Peck

On Sat, Jun 2, 2012 at 10:10 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I would need to debug memory leaks (maybe induced by announcements), and > for that I am thinking to use a graph of object references. > > I guess this would be easily possible with Fuel. If I have an object, how > would I go about doing this? > Hi Doru. Maybe this helps: http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/… (look at the end) cheers > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Don't give to get. Just give." > > > > > > > -- Mariano http://marianopeck.wordpress.com

June 2, 2012