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

Re: [Pharo-project] Method protocol nitpick

by Ben Coman

In MS Excel, such functions are grouped under "Information". Alternatively standardize a category "UnitTests". StÃ©phane Ducasse wrote: > I would like to recategorise systematically methods. > Would be good to propose some rules and apply automatically. > > Stef > > On Jun 2, 2012, at 7:42 PM, Sean P. DeNigris wrote: > > >> There are many test methods categorized as "testing". "Testing" means e.g. >> #isEmpty. "tests" (which is also used for test methods) would be better... >> >> Sean >> >> -- >> View this message in context: http://forum.world.st/Method-protocol-nitpick-tp4632925.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > >

June 3, 2012

[Pharo-project] McHttpRepository and text/plain

by Stuart Herring

Hi all, I recently ran into the problem with a server returning text/plain instead of application/octet stream again (see http://lists.gforge.inria.fr/pipermail/pharo-project/2012-April/062388.html) but the resulting error (a MNU for Character>>bitOr:) failed to job my memory as to the actual cause. Is there any chance the final line of McHttpRepository>>readStreamForFileNamed:do: could be changed from: ^ aBlock value: contents readStream to: ^ aBlock value: contents asByteArray readStream I know that it would be best if Web Servers never served up binary content as text/plain - but it's not always in the power of someone who encounters this error to fix that. Failing that, the condition should probably be explicitly checked for and a more useful error message given, as the cause is far enough away from the symptom that it takes a bit of digging to find out what went wrong. Regards, Stuart

June 3, 2012

Re: [Pharo-project] Tests jobs are non-functional

by Guillermo Polito

Found it! That test is sending twice the ClassRemoved event, the first succeeds, but on the second one fails because the class is not registered any more. I was trying this afternoon to replace the ugly ^nil by testing methods + exceptions, but I died in the trial. Tomorrow will be a new day :) On Sun, Jun 3, 2012 at 1:13 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Looks like the problem with Pharo-2.0-AfterRunningTests.st > > > > Notice: Errors in script loaded from > > /builds/jenkins/workspace/Pharo-2.0-Tests/Architecture/32/OS/linux/Pharo-2.0-AfterRunningTests/ > Pharo-2.0-AfterRunningTests.st > > =============================================================================== > [0m [0m [31m==== Startup Error: MessageNotUnderstood: receiver of > "removeClassDefinitionNamed:" is nil > [0mUndefinedObject(Object)>>doesNotUnderstand: > #removeClassDefinitionNamed: > RPackageOrganizer>>fullyRemoveClassNamed: > RPackageOrganizer>>systemClassRemovedActionFrom: > MessageSend>>value: > MessageSend>>cull: > MessageSend>>cull:cull: > AnnouncementSubscription>>deliver: in Block: [action cull: > anAnnouncement cull: announcer] > BlockClosure>>on:do: > BlockClosure>>on:fork: > AnnouncementSubscription>>deliver: > [0m [31mGot startup errors: > [0m [31m MessageNotUnderstood: receiver of > "removeClassDefinitionNamed:" is nil > [0mbuild.sh: error loading code > > (/builds/jenkins/workspace/Pharo-2.0-Tests/Architecture/32/OS/linux/vm/CogVM) > > > -- > Best regards, > Igor Stasenko. > >

June 3, 2012

Re: [Pharo-project] Log fwk

by Santiago Bragagnolo

I just refactor the hold logEntity for a announcer on the filter object (thanks Guille for the feedback :) ). But right now is based on TAnnouncer, an enhancement to announcements, that i recently commit. For a right-now functionaly log, checkout the 3rd commit! and not the last one, or, download the slice from PharoInbox previously. 2012/6/2 Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> > 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

[Pharo-project] Tests jobs are non-functional

by Igor Stasenko

Looks like the problem with Pharo-2.0-AfterRunningTests.st Notice: Errors in script loaded from /builds/jenkins/workspace/Pharo-2.0-Tests/Architecture/32/OS/linux/Pharo-2.0-AfterRunningTests/Pharo-2.0-AfterRunningTests.st =============================================================================== [0m[0m[31m==== Startup Error: MessageNotUnderstood: receiver of "removeClassDefinitionNamed:" is nil [0mUndefinedObject(Object)>>doesNotUnderstand: #removeClassDefinitionNamed: RPackageOrganizer>>fullyRemoveClassNamed: RPackageOrganizer>>systemClassRemovedActionFrom: MessageSend>>value: MessageSend>>cull: MessageSend>>cull:cull: AnnouncementSubscription>>deliver: in Block: [action cull: anAnnouncement cull: announcer] BlockClosure>>on:do: BlockClosure>>on:fork: AnnouncementSubscription>>deliver: [0m[31mGot startup errors: [0m[31m MessageNotUnderstood: receiver of "removeClassDefinitionNamed:" is nil [0mbuild.sh: error loading code (/builds/jenkins/workspace/Pharo-2.0-Tests/Architecture/32/OS/linux/vm/CogVM) -- Best regards, Igor Stasenko.

June 2, 2012

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