- Pharo-dev - lists.pharo.org

[Pharo-project] Gofer update broken ?

by arnaud Jean Baptiste

i try to update Gofer then Gofer gofer update. return a connection time out exception, server is broken ?

Dec. 1, 2009

[Pharo-project] gofer load make the categories don't appear

by arnaud Jean Baptiste

When i load a package Via Gofer, the categories of the loaded code doesn't appear. take a new image PharoCore1.1ALPHA Latest update: #11066 How to reproduce : execute : Gofer new squeaksource:'JBARepo'; addPackage:'FFI-Kernel'; load. then no categories FFI-kernel appear. but you can find the class loaded if you search them (FFIConstants or ExternalObject ) I open a issue : 1530

Dec. 1, 2009

Re: [Pharo-project] How do I know which issues are resolved in each new release?

by Tim Mackinnon

Actually I am thinking of something like the following (this is JBoss - they use Jira - which is free for open source projects, although I find it a bit clunky - but it gives an idea. I have actually seen Trac - the wiki and ticket system used very effectively); This link shows all of their version for the JBoss Web project: https://jira.jboss.org/jira/browse/JBWEB?report=com.atlassian.jira.plugin.s… This link shows what was fixed in 2.1.1 GA https://jira.jboss.org/jira/browse/JBWEB/fixforversion/12312592 I guess I am thinking that when I see the following in this list (from Marcus) - this information should appear somewhere as the things that were fixed in 9.11.5? 11066 ----- Issue 1526: remove #addInstanceVarNamed:withValue: Issue 1518: #abbreviatedBrowserButtons should be removed Issue 476: [Pending Etoy Cleaning] Object>>knownName Issue 1520: remove global References Tim On 30 Nov 2009, at 22:34, Michael Roberts wrote: > do you mean the svn thing? you can mark files in the repository in a > way that updates the issue tracker. I haven't tried it (we have no > files) but the docs look straightforward. It's meant for projects that > actually keep their source in the repository, but I think we could > have a dummy file that acted the same way. It would be a logical > closure for each issue to mark it with the update. That way it is > external to the image and gives the full life cycle on the tracker > which I think would be useful. > > cheers Mike > > On Mon, Nov 30, 2009 at 11:03 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I do not get it? >> Can you explain how this works? >> Because right now you take ScriptLoader and you get the log of all the issue that have been integrated. >> >> Stef >> >> On Nov 30, 2009, at 10:48 PM, Michael Roberts wrote: >> >>> you can check the log of the script loader. I don't have the code to >>> hand but check the state of the singleton I think. >>> >>> It might be nice in the future to use the google SVN feature to tag >>> issues with the image update as we close them. >>> >>> cheers, >>> Mike >>> >>> On Mon, Nov 30, 2009 at 10:24 PM, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: >>>> Hi guys - I noticed there was a new 9.11.4 release since buenos aires - and I got to wondering what issues have been resolved in it (as I am trying to follow Pharo by example - I am trying to test out features to see if they work as I progress through the material). >>>> >>>> Anyway - is there a list of issues fixed marked against each new version? I can see the list at: http://code.google.com/p/pharo/issues/list# - but it doesn't list any build numbers - just milestone 1.1? >>>> >>>> Tim >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 1, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Updated trunk image

by StÃ©phane Ducasse

thanks nicolas. The real problem we have is that fixes and improving the system takes too much times and we do not allocate time to improve the tools. For the integration we made progress I'm trying to get a webdav server (but I cannot reach the guy). I'm fighting to get some time to work on packages because we need a much better infrastructure. stef On Nov 30, 2009, at 11:24 PM, Nicolas Cellier wrote: > http://code.google.com/p/pharo/issues/detail?id=1527 > http://code.google.com/p/pharo/issues/detail?id=1528 > > A bit longer than I thought... > At the end, I used change list instead of merger, because I can see > method timestamp and isolate my own changes faster... > That another enhancement request toward MC... > > Nicolas > > 2009/11/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Yes I know. >> >> Stef >> >> On Nov 30, 2009, at 9:26 PM, Nicolas Cellier wrote: >> >>> 2009/11/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> ok so I imagine that this is already in pharo :) >>>> Excellent. >>>> >>>> Stef >>>> >>> >>> The only complication is that every DisplayScanner & co method was >>> reformatted in Pharo. >>> Chasing my own changes gets a bit tricky in these conditions... >>> I would need a special merger option to ignore formats (just scan code >>> and compare the sequence of tokens for example...). >>> >>> Nicolas >>> >>>> On Nov 30, 2009, at 8:35 PM, Nicolas Cellier wrote: >>>> >>>>> 2009/11/30 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: >>>>>> On 30.11.2009 19:29, StÃ©phane Ducasse wrote: >>>>>>>> >>>>>>>>>>> Collections >>>>>>>>>>> ----------- >>>>>>>>>>> Conversion of OrderedCollection and SortedCollection to Arrays has been sped up significantly. >>>>>>>>>>> >>>>>>>> Yes, it should be ported to Pharo, I see no reason of divergence there. >>>>>>>> >>>>>>> Yes and I like the fast in the sentence :) >>>>>> It's probably along the lines of what I did back in August for Pharo, >>>>>> using the array primitives directly, instead of copying the elements one >>>>>> by one. >>>>>> >>>>>> Cheers, >>>>>> Henry >>>>>> >>>>> >>>>> Oops, sorry, I did not noticed this one in Pharo and just rediscovered it. >>>>> My implementation is a bit shorter and yours is faster: >>>>> >>>>> asArray >>>>> "Overriden for speed" >>>>> ^array copyFrom: firstIndex to: lastIndex >>>>> >>>>> Cheers >>>>> >>>>> Nicolas >>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 1, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Updated trunk image

by StÃ©phane Ducasse

>>> The only complication is that every DisplayScanner & co method was >> reformatted in Pharo. >> Chasing my own changes gets a bit tricky in these conditions... >> I would need a special merger option to ignore formats (just scan code >> and compare the sequence of tokens for example...). >> > > Oh, and the second complication is *Freetype-override... > I would like to not see that stuff ! We do not want override in the system. Especially because I remember that a while back there was a bug when unloading package in presence of override. I found strange that we have this kind of code in override especially since part of it is dead as implemented by dan. crossedX "Text display has wrapping. The scanner just found a character past the x location of the cursor. We know that the cursor is pointing at a character or before one." | leadingTab currentX | characterIndex == nil ifFalse: [ "If the last character of the last line is a space, and it crosses the right margin, then locating the character block after it is impossible without this hack." characterIndex > text size ifTrue: [ lastIndex := characterIndex. characterPoint := (nextLeftMargin ifNil: [leftMargin]) @ (destY + line lineHeight). ^true]]. characterPoint x <= (destX + (lastCharacterExtent x // 2)) ifTrue: [lastCharacter := (text at: lastIndex). characterPoint := destX @ destY. ^true]. lastIndex >= line last ifTrue: [lastCharacter := (text at: line last). characterPoint := destX @ destY. ^true]. "Pointing past middle of a character, return the next character." lastIndex := lastIndex + 1. lastCharacter := text at: lastIndex. currentX := destX + lastCharacterExtent x + kern. self lastCharacterExtentSetX: (font widthOf: lastCharacter). characterPoint := currentX @ destY. lastCharacter = Space ifFalse: [^ true]. "Yukky if next character is space or tab." alignment = Justified ifTrue: [self lastCharacterExtentSetX: (lastCharacterExtent x + (line justifiedPadFor: (spaceCount + 1) font: font)). ^ true]. true ifTrue: [^ true]. "NOTE: I find no value to the following code, and so have defeated it - DI" "See tabForDisplay for illumination on the following awfulness." leadingTab := true. line first to: lastIndex - 1 do: [:index | (text at: index) ~= Tab ifTrue: [leadingTab := false]]. (alignment ~= Justified or: [leadingTab]) ifTrue: [self lastCharacterExtentSetX: (textStyle nextTabXFrom: currentX leftMargin: leftMargin rightMargin: rightMargin) - currentX] ifFalse: [self lastCharacterExtentSetX: (((currentX + (textStyle tabWidth - (line justifiedTabDeltaFor: spaceCount))) - currentX) max: 0)]. ^ true

Dec. 1, 2009

[Pharo-project] [update 1.1] #11066

by Marcus Denker

11066 ----- Issue 1526: remove #addInstanceVarNamed:withValue: Issue 1518: #abbreviatedBrowserButtons should be removed Issue 476: [Pending Etoy Cleaning] Object>>knownName Issue 1520: remove global References postscript does: Preferences removePreference: #abbreviatedBrowserButtons. Smalltalk removeKey: #References.

Dec. 1, 2009

Re: [Pharo-project] Is there something wrong in debugging in the Morphic thread?

by HernÃ¡n Morales Durand

Hi Simon, Have you tried http://www.squeaksource.com/LightweightClasses.html ? It's in an experimental stage, but I've used it succesfully for the recursive debugger problem. You may load it in Pharo-Core this way : Gofer new squeaksource: 'LightweightClasses'; addPackage: 'ParametrizedCompiler'; addPackage: 'LightweightClasses'; addPackage: 'OBLightweightClass'; load; recompile. Cordialement, HernÃ¡n 2009/11/30 Simon Denier <simon.denier(a)inria.fr>: > > Unfortunately, this is an issue which I cant easily reproduce, at least not > without a third party tool (1525). Now I would like the general > opinion/experience of debugging Morphic code especially in threads. > Usually an exception raised from within Morphic code pops up a debugger as > usual. However, from time to time, or for more complicated stuff, the > situation runs out of hand and tons of debugger pop up everywhere because > the same faulty gets obviously executed again and again. > Now can somebody with some Morphic knowledge explain how this is supposed to > work and how to deal with such issues? > -- > Â Simon > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 1, 2009

Re: [Pharo-project] Is there something wrong in debugging in the Morphic thread?

by Marcus Denker

On Nov 30, 2009, at 10:51 PM, Henrik Sperre Johansen wrote: > On 30.11.2009 22:06, Schwab,Wilhelm K wrote: >> >> >> (2) Debugging drawing code is probably best done using a single-shot breakpoint. I _think_ I have seen something about halt once in Pharo. FWIW, somebody posted a class called Once that creates such a feature that looks like >> >> Once do:[ >> "do anything here, but this is common:" >> self halt. >> ]. >> >> Somewhere you need to do Once reset or something (it's obvious from the code) to enable the breakpoint. Once evaluates the block one time, and then won't evaluate the block again until told to do so. If there is a need for this in Pharo, I should be able to "port" it - IIRC, it was licensed for public consumption. > It exists already, is called haltOnce, and is used in the same manner as halt. To arm it, evaluate Object setHaltOnce. Make sure to remove them when you finish debugging though, since the overhead is non-negligible. In addition, I added a trivial version of "contextual" or "subjective" halt feature to #haltIf:. It looks up the stack and only halts if there is a method with the name if the parameter is a symbol. Thus you can do: self haltIf: #testThatIWrote Of course, at some point (years, not days, I fear) we will make the deep principle that is hidden in this idea a core feature of the reflective model... Marcus

Dec. 1, 2009

[Pharo-project] Running all tests in core 11065?

by Simon Denier

Did someone manage to run all the tests in the latest core image (11065, updated from 11053). I try to compare the state of tests before/after some changes, but in both cases the test runner got stuck around 1600 tests. -- Simon

Dec. 1, 2009

Re: [Pharo-project] How do I know which issues are resolved in each new release?

by Dale Henrichs

In the google issues list, one can add a column called "Fixed" and a version can be supplied for the value of that field (like Version or Milestone) when the bug is fixed ... I think this is what Tim is getting at. I've just done this for Metacello, since I think it is a good idea:) Dale ----- "Tim Mackinnon" <tamackinnon(a)gmail.com> wrote: | Hi guys - I noticed there was a new 9.11.4 release since buenos aires | - and I got to wondering what issues have been resolved in it (as I am | trying to follow Pharo by example - I am trying to test out features | to see if they work as I progress through the material). | | Anyway - is there a list of issues fixed marked against each new | version? I can see the list at: | http://code.google.com/p/pharo/issues/list# - but it doesn't list any | build numbers - just milestone 1.1? | | Tim | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 1, 2009