- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Xtreams in Pharo 3

by StÃ©phane Ducasse

If Xtreams goes in the core of Pharo (which could be good), there should be no compatibility layers with others platforms. Sorry but we have too many of them and we do not want to have strings attached. if necessary we can rename the complete library so that people can load the real CrossPlatformXtream projects on top of Pharo. I'm not sure that people can understand that but this is important. And we do not do that for the sake of it. As one of the keeper of the core I do not want to have to think about systems I do not know. Stef >> It's Pharo specific at the moment AFAICT because it refers to >> FileHandle and FileReference, while the upstream repo uses >> FSFileHandle and FSFileReference. The conversation's partly at >> https://code.google.com/p/xtreams/issues/detail?id=2 > > Thanks, Frank, for the explanation. Conclusion: for now it can be consider Pharo only (but given some class renames, it should be broader). > > With/without prefixes is one aspect, forking/not-forking another. > > Like I said, and like you acknowledged, it is possible to keep things together, but it requires real, continuous effort from all sides. > > Sven

Nov. 23, 2013

Re: [Pharo-dev] Patches for Pharo packages you are maintaining

by StÃ©phane Ducasse

On Nov 23, 2013, at 9:51 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > opened https://pharo.fogbugz.com/f/cases/12229/XML-Tools-improvement otherwise these changes are as good as lost. > sending mcz via mail is from the last century. I did not say it like that but indeed I would prefer that people have account on Smalltalkhub :) > > On 2013-11-23, at 09:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> No time so fr to handle it. >> >> Stef >> >> Begin forwarded message: >> >>> From: "monty" <monty.os(a)engineer.com> >>> Subject: Patches for Pharo packages you are maintaining >>> Date: November 21, 2013 3:14:25 AM GMT+01:00 >>> To: stephane.ducasse(a)inria.fr >>> >>> Prof. Stef, I have produced updates to the XML-Parser, XML-Parser-Testing, and XML-Writer-Core packages you are maintaining. >>> >>> These updates add validation against internal and external DTDs, proper replacement of general and parameter entites, customizable resolution of external parsed entities using Zinc and FileSystem, awareness of notations and unparsed entities, preservation of the internal DTD subset by the DOM parser (so printing a parsed doc with a DTD will produce approximately what was input), line numbers reporting in error messages, and better well-formed and validity constraints. >>> >>> I had to largely rewrite the tokenizer to make everything work, but I followed the spec closely, and it is about the same speed as long as there is no DTD to validate against. >>> >>> One problem is that while the tests I added and the existing tests all pass, for some reason helper messages in some test classes starting with "should" (in the style of should:raise:) are being interpreted as tests and run by TestRuner, even though they don't begin with "test" and take arguments! This is possibly a bug in TestRunner. >>> >>> Another problem is that there are so many deprecated methods cluttering up classes, some of which have been deprecated for years! It is confusing and hard to see which methods to use just by browsing the protocols. I would really suggest using this code to get rid of the XML-Parser methods that have been deprecated for at least a year: >>> >>> expiry := 1 year. >>> (SystemNavigation default allClassesInPackageNamed: 'XML-Parser') >>> do: [:class | >>> class selectors do: [:selector | | compiledMethod timeStamp | >>> compiledMethod := class compiledMethodAt: selector. >>> timeStamp := compiledMethod timeStamp copyAfter: Character space. >>> (compiledMethod isDeprecated >>> and: [(DateAndTime now - (DateAndTime fromString: timeStamp)) > expiry]) >>> ifTrue: [class removeSelector: selector]]]. >>> >>> I ran and checked it myself and it doesn't break anything. Running the above with XML-Writer-Core might not be a bad idea either. >>> >>> I also updated BitmapCharacterSet to use less memory. >> <XML-Writer-Core-monty.5.mcz> >> <XML-Tests-Parser-monty.27.mcz> >> <XML-Parser-monty.173.mcz> >> <Collections-BitmapCharacterSet-Anonymous.6.mcz> >> <Collections-BitmapCharacterSet-Anonymous.6.mcz> >> >

Nov. 23, 2013

Re: [Pharo-dev] Patches for Pharo packages you are maintaining

by Camillo Bruni

opened https://pharo.fogbugz.com/f/cases/12229/XML-Tools-improvement otherwise these changes are as good as lost. sending mcz via mail is from the last century. On 2013-11-23, at 09:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > No time so fr to handle it. > > Stef > > Begin forwarded message: > >> From: "monty" <monty.os(a)engineer.com> >> Subject: Patches for Pharo packages you are maintaining >> Date: November 21, 2013 3:14:25 AM GMT+01:00 >> To: stephane.ducasse(a)inria.fr >> >> Prof. Stef, I have produced updates to the XML-Parser, XML-Parser-Testing, and XML-Writer-Core packages you are maintaining. >> >> These updates add validation against internal and external DTDs, proper replacement of general and parameter entites, customizable resolution of external parsed entities using Zinc and FileSystem, awareness of notations and unparsed entities, preservation of the internal DTD subset by the DOM parser (so printing a parsed doc with a DTD will produce approximately what was input), line numbers reporting in error messages, and better well-formed and validity constraints. >> >> I had to largely rewrite the tokenizer to make everything work, but I followed the spec closely, and it is about the same speed as long as there is no DTD to validate against. >> >> One problem is that while the tests I added and the existing tests all pass, for some reason helper messages in some test classes starting with "should" (in the style of should:raise:) are being interpreted as tests and run by TestRuner, even though they don't begin with "test" and take arguments! This is possibly a bug in TestRunner. >> >> Another problem is that there are so many deprecated methods cluttering up classes, some of which have been deprecated for years! It is confusing and hard to see which methods to use just by browsing the protocols. I would really suggest using this code to get rid of the XML-Parser methods that have been deprecated for at least a year: >> >> expiry := 1 year. >> (SystemNavigation default allClassesInPackageNamed: 'XML-Parser') >> do: [:class | >> class selectors do: [:selector | | compiledMethod timeStamp | >> compiledMethod := class compiledMethodAt: selector. >> timeStamp := compiledMethod timeStamp copyAfter: Character space. >> (compiledMethod isDeprecated >> and: [(DateAndTime now - (DateAndTime fromString: timeStamp)) > expiry]) >> ifTrue: [class removeSelector: selector]]]. >> >> I ran and checked it myself and it doesn't break anything. Running the above with XML-Writer-Core might not be a bad idea either. >> >> I also updated BitmapCharacterSet to use less memory. > <XML-Writer-Core-monty.5.mcz> > <XML-Tests-Parser-monty.27.mcz> > <XML-Parser-monty.173.mcz> > <Collections-BitmapCharacterSet-Anonymous.6.mcz> > <Collections-BitmapCharacterSet-Anonymous.6.mcz> >

Nov. 23, 2013

Re: [Pharo-dev] How to use Opal for parsing peace of code?

by Marcus Denker

On 23 Nov 2013, at 09:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > other notes: > > - the faulty (code with syntax error) parsing is very much an experiment. Do you need it? > - maybe for now just using RPParser directly is better. - there is no concept of âexecutable expressionâ in Smalltalk. Everything compiled to bytecode has to be a method. This is why expressions are compiled to DoIt methods, transforming the AST of the expression into a method. Marcus

Nov. 23, 2013

Re: [Pharo-dev] How to use Opal for parsing peace of code?

by Marcus Denker

On 23 Nov 2013, at 09:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > E.g. there are lots of references to RBParser in the Refactoring Engine. The problem is that is we replace > them now, then all these uses break when you switch to the old Compiler as it uses a different API. ^^^^^^^ AST > > So summary: it needs more work, but we can only do that in Pharo4. > Sadly. But itâs like it is. Putting now effort into it with keeping the old Compiler compatible would just be wasted effort. Removing the old Compiler now I donât want to do either because all the change that we would want to do after is of the kind that one should not do a week before freezing for the release. Marcus

Nov. 23, 2013

Re: [Pharo-dev] How to use Opal for parsing peace of code?

by Marcus Denker

On 22 Nov 2013, at 21:58, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > Hi! > > I am interested how to use Opal for parsing peace of code. I have supposed to use something like this: > > | root node1 node2 | > root := OpalCompiler new > source: 'Color blue yourself'; > useFaultyForParsing: true; > parse. > root doSemanticAnalysis. > node1 := root bestNodeFor: (2 to: 2). > node2 := root bestNodeFor: (7 to: 7). > > But node1 is a RBMethodNode, and node2 is a RBVariableNode. > > Does it matter if source for OpalCompiler is peace of code or method source? > Yes, by default it parses methods. When you tell it to parse expressions, it parses them as doit-methods (it wraps them into a method node named DoIt and adds a return at the end). We need to provide a way that it can parse expressionsâ¦ or maybe hide the Doit transform in the âcompileâ while the parse gives you an untransformed expression? We need to do some more iterations on the API to make it nice to use as a general facade for the Parser. Right now the API was driven purely by replacing existing usage without too much change, as both Compiler and OpalCompiler have the same API (they are exchangeable). Doing the second iteration with keeping compatibility would be quite a challenge (and not fun to do), so I will start with that as soon as we retire the old compiler and thus are in a position to really clean up. other notes: - the faulty (code with syntax error) parsing is very much an experiment. Do you need it? - maybe for now just using RPParser directly is better. Yes, we need to enhance the OpalCompiler API to be good enough to not need any direct references to any Parser (so people can plug their own). E.g. there are lots of references to RBParser in the Refactoring Engine. The problem is that is we replace them now, then all these uses break when you switch to the old Compiler as it uses a different API. So summary: it needs more work, but we can only do that in Pharo4. Marcus

Nov. 23, 2013

Fwd: Patches for Pharo packages you are maintaining

by StÃ©phane Ducasse

No time so fr to handle it. Stef Begin forwarded message: > From: "monty" <monty.os(a)engineer.com> > Subject: Patches for Pharo packages you are maintaining > Date: November 21, 2013 3:14:25 AM GMT+01:00 > To: stephane.ducasse(a)inria.fr > > Prof. Stef, I have produced updates to the XML-Parser, XML-Parser-Testing, and XML-Writer-Core packages you are maintaining. > > These updates add validation against internal and external DTDs, proper replacement of general and parameter entites, customizable resolution of external parsed entities using Zinc and FileSystem, awareness of notations and unparsed entities, preservation of the internal DTD subset by the DOM parser (so printing a parsed doc with a DTD will produce approximately what was input), line numbers reporting in error messages, and better well-formed and validity constraints. > > I had to largely rewrite the tokenizer to make everything work, but I followed the spec closely, and it is about the same speed as long as there is no DTD to validate against. > > One problem is that while the tests I added and the existing tests all pass, for some reason helper messages in some test classes starting with "should" (in the style of should:raise:) are being interpreted as tests and run by TestRuner, even though they don't begin with "test" and take arguments! This is possibly a bug in TestRunner. > > Another problem is that there are so many deprecated methods cluttering up classes, some of which have been deprecated for years! It is confusing and hard to see which methods to use just by browsing the protocols. I would really suggest using this code to get rid of the XML-Parser methods that have been deprecated for at least a year: > > expiry := 1 year. > (SystemNavigation default allClassesInPackageNamed: 'XML-Parser') > do: [:class | > class selectors do: [:selector | | compiledMethod timeStamp | > compiledMethod := class compiledMethodAt: selector. > timeStamp := compiledMethod timeStamp copyAfter: Character space. > (compiledMethod isDeprecated > and: [(DateAndTime now - (DateAndTime fromString: timeStamp)) > expiry]) > ifTrue: [class removeSelector: selector]]]. > > I ran and checked it myself and it doesn't break anything. Running the above with XML-Writer-Core might not be a bad idea either. > > I also updated BitmapCharacterSet to use less memory.

Nov. 23, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by Camille Teruel

On 22 nov. 2013, at 21:03, Chris Muller <asqueaker(a)gmail.com> wrote: > How does this affect serialization / materialization engines like Fuel? That's a good question Chris! My impression is that serialization / materialization should not trigger custom read / write slot logic. Fuel should serialize objects as they are in memory not how they appear through the read/write slot methods. For example, imagine you have a HistorySlot that stores the history of the different writes. The actual associated field would be an ordered collection, the write method would add a new value to this collection and the read method would return the last element of the list. So an object whose class use such a slot would point to an ordered collection but through the slot logic it would appear to point to the last element of that collection. Then when you want to serialize an instance of a class that use such a slot, I think you want to serialize the whole collection not only the last value. Because else the materialization would create an object whose state is inconsistant with the slot logic (you could have DNUs like "SomeClass does not understand: #addLast:" on writes and "SomeClass does not understand: #last" on reads). So, IMO Fuel should work like it works today, without taking slots into account. But maybe they are some weird cases where you want to trigger the slot logic, I don't know. > > On Thu, Nov 21, 2013 at 7:24 AM, Camille Teruel > <camille.teruel(a)gmail.com> wrote: >> >> On 21 nov. 2013, at 13:44, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> any links why newcomers like me should be impressed ? Whats the advantages ? >> >> >> That's just cleaning. The old class builder was an incredibly complex piece >> of code that is now replaced with the Slot class builder. >> The later is based on slots and is much more understandable and thus much >> easier to maintain. >> It's been integrated some time ago thanks to Martin. >> >> Slots are the work of Toon and Camillo and enables a lot of useful features: >> http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectL… >> They are based on the reification of class layouts (variable,weak,fixed and >> co) and instance variables (slots). >> Slots are an abstraction added on top of low-level class "fields". >> It means that one will be able to create a customized slot class that define >> the logic to read and write a slot: >> >> Object subclass: #MyClass >> slots: { x => MyFancySlot } >> category: 'Playground' >> >> Then when a method read or writes x, the logic you defined in MyFancySlot is >> executed. >> All that still need to be absorbed by Opal so it's not available right now >> but it will (Pharo 4)! >> >> >> >> >> >> On Thu, Nov 21, 2013 at 2:21 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Triple impressive! This is another sample of an apparently tiny change >>> that actually has deep impact on the future of our beloved environment. >>> >>> Ladies and gentlemen, I know you are busy, but please take the time to >>> acknowledge it :) >>> >>> Doru >>> >>> >>> >>> >>> On Thu, Nov 21, 2013 at 12:58 PM, Martin Dias <tinchodias(a)gmail.com> >>> wrote: >>>> >>>> wow, impressive! >>>> >>>> >>>> On Thu, Nov 21, 2013 at 9:02 AM, Marcus Denker <marcus.denker(a)inria.fr> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Yesterday Camille did the change to finally remove the old class >>>>> builder! >>>>> (just a removal + a small change to NativeBoost to use the new class >>>>> builder to create anonymous classes). >>>>> >>>>> This means >>>>> - 1000 Loc of completely un-understandable code removed. >>>>> - we now 100% run on the new class builder from the Slot >>>>> Project. >>>>> >>>>> Next on the list (not all for Pharo3): >>>>> >>>>> - remove PackageInfo >>>>> - old Browser + CodeHolder hierarchy >>>>> - PseudoClass&Co â> Ring >>>>> - old AST+Compiler (this in Pharo4) >>>>> >>>>> We already did (all in Pharo3): >>>>> -> remove URI >>>>> -> deprecated Url for ZnUrl >>>>> -> removed HTTPSocket facade >>>>> -> MIMEType retired for ZnMimeType >>>>> -> old Debugger is removed >>>>> -> Class categories are replaced by Protocols >>>>> >>>>> I am quite sure that these cleanups will enable us to build a lot of >>>>> very interesting things >>>>> in the future. >>>>> >>>>> Marcus >>>> >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> >> >> >

Nov. 22, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by Nicolas Cellier

OK, got it, nothing tells that they come from same slot... At least you have a pre-filter. 2013/11/22 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > (true pointersTo collect: #class as: Set) intersection: (false pointersTo > collect: #class as: Set) > > et voila > > > 2013/11/22 Stephan Eggermont <stephan(a)stack.nl> > >> Nicolas wrote: >> >It has to be more simple than thatâ¦ >> >> Probably. I donât do this often enough. >> >> >Why not searching for allReferences to true and false, and gather the >> class of referents? >> >> How is that going to give me the values of the instVars? >> >> >This would also remove the limitation of first 10 instancesâ¦ >> >> Taking a look at all instances just takes a bit longer... >> >> Iâm open to suggestions. >> >> Stephan >> >> >> >> >

Nov. 22, 2013

Re: [Pharo-dev] Old ClassBuilder remove!

by Nicolas Cellier

(true pointersTo collect: #class as: Set) intersection: (false pointersTo collect: #class as: Set) et voila 2013/11/22 Stephan Eggermont <stephan(a)stack.nl> > Nicolas wrote: > >It has to be more simple than thatâ¦ > > Probably. I donât do this often enough. > > >Why not searching for allReferences to true and false, and gather the > class of referents? > > How is that going to give me the values of the instVars? > > >This would also remove the limitation of first 10 instancesâ¦ > > Taking a look at all instances just takes a bit longer... > > Iâm open to suggestions. > > Stephan > > > >

Nov. 22, 2013