- Pharo-dev - lists.pharo.org

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

by Esteban Lorenzano

On Sun, Nov 24, 2013 at 10:29 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > > I like the monkeyâ¦ > > > we talk about the picture > yeah, I know... me too, I like it :D (but as I say, I do not care about it :P) > > but I really don't care if is there or not. > Now... I think there are some real bugs in the bug tracker (like not > updating the list). > > I do not like fogbugz, I find it heavy, hard to use and a real pain in my > ***, but I also think that "you do not change horses in the middle of the > race" :) > > Esteban > > > On Sun, Nov 24, 2013 at 12:38 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> killing ugly monkey picture: +1000! (a reason why I don't go there BTW, >> it scares me). >> >> Phil >> >> >> >> >> On Sat, Nov 23, 2013 at 10:27 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> >>> >>> >> >>> >> So registering on Pharo tracker *never* worked for me, since I try, >>> >> before the summer. >>> >> >>> > >>> > In the end I think is was a mistake to use fogbugz. For sure itâs nice >>> for companies, but >>> > for open sourse projects it just does not work with a closed bug >>> tracker. >>> > >>> > Now the question is what is the effort to move to yet another one? >>> >>> I do not like fogbugz but I would not change now. >>> Let us >>> - make it easy for people to log >>> - remove this ugly monkey pictures (I do not like it - do you >>> think that people can understand anything with it. >>> - get a newer version of smalltalkhub >>> and continue. >>> >>> Stef >>> >>> >>> >> > >

Nov. 24, 2013

Re: [Pharo-dev] Nautilus no longer guards against changed methods

by Sven Van Caekenberghe

On 24 Nov 2013, at 10:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > open a bug entry It might be a duplicate, or related to similar problems that were reported: https://pharo.fogbugz.com/f/cases/12230/Nautilus-no-longer-guards-against-c… > We should have a meeting to check all the bugs that we should address. > > >> I think this has been reported before, but in #30591 Nautilus no longer guards against changed methods. >> >> - Open Nautilus, select some method in some class >> - Change the methodâs source code, orange in top right corner >> - Click any other method, category, class or package >> - Pending change is lost >> >> This is pretty importart, I lost some changes already. >> >> Sven >> >> > >

Nov. 24, 2013

Fwd: Patches for Pharo packages you are maintaining

by StÃ©phane Ducasse

I will sycn the package and update the configuration. I added monty to the XMLReader and XMLWriter PharoExtras packages. Begin forwarded message: > From: "monty" <monty.os(a)engineer.com> > Subject: Re: Patches for Pharo packages you are maintaining > Date: November 24, 2013 3:17:01 AM GMT+01:00 > To: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > > I created a Smalltalkhub account and uploaded the latest versions of my packages there: http://smalltalkhub.com/#!/~monty/XMLPackages > > I was able to use the existing parsing infrastructure to build a tolerant HTML parser that produces a DOM tree. I am not sure if this should be standard or packaged separately. The relevant classes are in XML-Parser-HTML, if Damien (or whoever) wants to extract them. > > I also added support for standlone="yes" declarations and made the path resolution more robust. > > XMLParser now fully supports all the features of the XML 1.0 and namespaces 1.0 specs. This is a great news > >> ----- Original Message ----- >> From: StÃ©phane Ducasse >> Sent: 11/21/13 03:19 PM >> To: monty >> Subject: Re: Patches for Pharo packages you are maintaining >> >> > I don't have a Smalltalkhub account >> >> you should get one because it is cool and good. >> You should published there because when you publish the code it is explicit that this is under MIT. >> >> > and haven't signed any documents, but all my contributions have been derivative and should be automatically licensed under MIT (or whatever the original licenses of the packages are). >> >> MIT. >> It is important also for Pharo to have more contributors so if you can sign the license agreement I can like that archive it. :). >> >> Setf >> >> > >> > ----- Original Message ----- >> > From: StÃ©phane Ducasse >> > Sent: 11/21/13 06:17 AM >> > To: monty >> > Subject: Re: Patches for Pharo packages you are maintaining >> > ***excellent *** >> > >> > do you have an account on smalltalkhub so that I can give you access to it? >> > Did you sign the license agreement that you can find on the web? >> > >> > Stef >> > >> > >> > On Nov 21, 2013, at 3:14 AM, "monty" <monty.os(a)engineer.com> wrote: >> > >> >> Prof. Stef, I have produced updates to the XML-Parser, XML-Parser-Testing, and XML-Writer-Core packages you are maintaining. >> > >> > I'm not maintaining it, just making sure that we can load them. >> > >> >> 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. >> > >> > Indeed this looks strange, >> > >> >> 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: >> > >> > Yes :) >> > >> > >> >> >> >> 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. >> > >> > excellent >> > With metacello we will just create a new version/baseline and people relying on XML can choose when they want to migrate. >> > >> >> <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. 24, 2013

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

by StÃ©phane Ducasse

> I like the monkeyâ¦ we talk about the picture > but I really don't care if is there or not. > Now... I think there are some real bugs in the bug tracker (like not updating the list). > > I do not like fogbugz, I find it heavy, hard to use and a real pain in my ***, but I also think that "you do not change horses in the middle of the race" :) > > Esteban > > > On Sun, Nov 24, 2013 at 12:38 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > killing ugly monkey picture: +1000! (a reason why I don't go there BTW, it scares me). > > Phil > > > > > On Sat, Nov 23, 2013 at 10:27 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >>> > >> > >> So registering on Pharo tracker *never* worked for me, since I try, > >> before the summer. > >> > > > > In the end I think is was a mistake to use fogbugz. For sure itâs nice for companies, but > > for open sourse projects it just does not work with a closed bug tracker. > > > > Now the question is what is the effort to move to yet another one? > > I do not like fogbugz but I would not change now. > Let us > - make it easy for people to log > - remove this ugly monkey pictures (I do not like it - do you think that people can understand anything with it. > - get a newer version of smalltalkhub > and continue. > > Stef > > > >

Nov. 24, 2013

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

by StÃ©phane Ducasse

On Nov 23, 2013, at 10:51 PM, Lorenz KÃ¶hl <lorenz(a)quub.de> wrote: >>>> So registering on Pharo tracker *never* worked for me, since I try, >>>> before the summer. >>> In the end I think is was a mistake to use fogbugz. For sure itâs nice for companies, but >>> for open sourse projects it just does not work with a closed bug tracker. >>> >>> Now the question is what is the effort to move to yet another one? >> I do not like fogbugz but I would not change now. >> Let us >> - make it easy for people to log > > The Racket programming language (racket-lang.org) has in its IDE DrRacket a menu item > - Submit bug report > > Details about the system and a description of the bug is gathered and sent of to a bugs mailing list as well as creating an issue in a bug tracker. This way you get the issue number, a possible discussion thread about the bug/enhancement and any user can take part. IMHO this is the _right_ way to do it. Long long time ago all the bugs could be submitted from Squeak itself (way before racket even started to exist) and we add a tool to crawl the emails and sort the bugs and it was a lot of work. So the Right way is something to evaluate and learn. > > Is there something similar for pharo? No but it was planned now if people can publish bug at a fast rate (and may be there are not bug) our question is: is it really reasonable to overwhelm with bugs :) > Contributing changes this way might get more complicated though, but possible.

Nov. 24, 2013

Re: [Pharo-dev] Nautilus no longer guards against changed methods

by StÃ©phane Ducasse

open a bug entry We should have a meeting to check all the bugs that we should address. > I think this has been reported before, but in #30591 Nautilus no longer guards against changed methods. > > - Open Nautilus, select some method in some class > - Change the methodâs source code, orange in top right corner > - Click any other method, category, class or package > - Pending change is lost > > This is pretty importart, I lost some changes already. > > Sven > >

Nov. 24, 2013

Re: [Pharo-dev] Slot class builder: Anonymous class modification

by StÃ©phane Ducasse

So I'm confused. what does it means in Java? What is the meaning (I know that anonymous are the one with $ in the name when looking at them from the Java bycode point of view) but beside that? > Indeed. Same for listeners etc. > > Anonymous class has indeed a very clear meaning to me and to any student that has been exposed to Java (which means "a huge lot"). > > Phil > > > On Sun, Nov 24, 2013 at 1:20 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2013/11/23 Igor Stasenko <siguctua(a)gmail.com>: > > On 23 November 2013 21:26, Esteban A. Maringolo <emaringolo(a)gmail.com> > >> >> imo, a better term to use for it would be 'private class' , because > >> >> anonymous is a bit fuzzy. > > >> > I disagree. Anonymous classes is the term that has been used for over > >> > two decades. It means, literally, a class that has no name because it is > >> > not in Smalltalk (or in a top-level environment if the dialect has > >> > namespaces). This is not at all fuzzy. Private class means something quite > >> > different, a class that is private to some environment, e.g. a class nested > >onyl> > within another class as occurs in SmalltalkAgents or Newspeak. > >> > >> +1 > >> > >> Anonymous = without name. > >> There's not much to add to it. > > > That's the point. Now what is practical implications of it? > > Think, how far you can go with anonymous versus private class. > > > > If you deny anonymous classes from being private, > > then you'll immediately hit many problems with tools, > > which working with public classes and expecting them to have a name. > > And i don't have to go deep to point on problems: just imagine that you did > > a change to such 'anonymous' class, now since it is public, all tools is > > notified about this change, including change logger.. and my question, what > > you going to log into .changes file in such case? > > I can see your point. But then just say that "Anonymous classes are private". > Just don't change the name. Anonymous classes are a well know concept > used through piles of literature. > E.g. In Java the compiler creates anonymous classes everytime you > directly instantiate an Interface. > > ej myObject.schedule(new Runnable {...}); > > Regards, > >

Nov. 24, 2013

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

by Esteban Lorenzano

he, no, we are not going to re-migrate anytime soon :) last year we needed a solution and we find it with fogbugz. Now, probably it does not fits completely with our process or our openness our other stuff, but still we have a reality: changing it is a lot of effort and even if fogbugz is not perfect, it works. So... until we have time and a *proven* better solution, we will not change it. As Stef said, the right step (now) is to make what we have work better, not run away from it :) And of course, I'm not saying not to change ever... just not doing it impulsively and without reasoning... Esteban On Sun, Nov 24, 2013 at 10:15 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > For the easiest thing in town, I'd say "Atlassian Jira" > https://www.atlassian.com/opensource/overview > > I am using Fogbugz and JIRA on several client projects and JIRA definitely > has more traction and engagement. > > But, migrating may be less painful than before: > https://confluence.atlassian.com/display/JIRA/Importing+Data+from+FogBugz+f… > > https://www.atlassian.com/software/jira/importer-migrations#!jira-fogbugz > > > Phil >

Nov. 24, 2013

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

by phil＠highoctane.be

For the easiest thing in town, I'd say "Atlassian Jira" https://www.atlassian.com/opensource/overview I am using Fogbugz and JIRA on several client projects and JIRA definitely has more traction and engagement. But, migrating may be less painful than before: https://confluence.atlassian.com/display/JIRA/Importing+Data+from+FogBugz+f… https://www.atlassian.com/software/jira/importer-migrations#!jira-fogbugz Phil

Nov. 24, 2013

Nautilus no longer guards against changed methods

by Sven Van Caekenberghe

I think this has been reported before, but in #30591 Nautilus no longer guards against changed methods. - Open Nautilus, select some method in some class - Change the methodâs source code, orange in top right corner - Click any other method, category, class or package - Pending change is lost This is pretty importart, I lost some changes already. Sven

Nov. 24, 2013