December 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3463 in pharo: [Failing Test] HelpBrowserTest.testOpen

by pharo＠googlecode.com

Updates: Cc: laurent.laffont Comment #4 on issue 3463 by Torsten....(a)astares.de: [Failing Test] HelpBrowserTest.testOpen http://code.google.com/p/pharo/issues/detail?id=3463 OK, to give more context: - the test HelpBrowserTest.testOpen just checks if the help browser can be opened without any problem (by checking if an exception occurs) - unfortunately there is an exception thrown Why: - one of the included help books is Laurents "SmalltalkSyntaxTutorial" - this class is instantiated and during intialization it sends #prepareDebuggerExample - this method compiles some code which ends up in the method CompiledMethod>>putSource:fromParseNode:inFile:withPreamble: - this method signals the exception: InMidstOfFileinNotification signal ifFalse: [file flush]. - this can be reproduced with the following code: [Object compile: 'foo ^3+4' classified: 'test'] on: Exception do: [:ex | ex inspect] This also gives the InMidstOfFileinNotification Dont know why this InMidstOfFileinNotification Possible Solutions: - handle the notification in #prepareDebuggerExample (while compiling the code) - maybe we should also change #testOpen to just check for errors instead of exception while opening: self shouldnt: block raise: Error (this would avoid notifications which are also exceptions)

Dec. 20, 2010

Re: [Pharo-project] Issue 3454 in pharo: DNU when looking for implementors in OB on 1.2dev

by pharo＠googlecode.com

Updates: Cc: -renggli Comment #7 on issue 3454 by luc.fabresse: DNU when looking for implementors in OB on 1.2dev http://code.google.com/p/pharo/issues/detail?id=3454 Yes I don't know the impact of removing the #terminateAndInitializeAround: message send. That's why I did not provide a fix.

Dec. 20, 2010

Re: [Pharo-project] Dear Santa ...

by Steve Wart

Stephen Taylor <stephen.taylor(a)bom.gov.au> wrote: > Janko MivÅ¡ek wrote: > >> - Namespaces > > +1 - that would be a very nice present. > +1 - this is a longstanding wish for many people. is it too controversial to wonder if Pharo/Squeak namespaces can be compatible with VisualWorks? I also miss the days of a compatible chunk format. Monticello is nice when it works, but it's always been a bit frustrating to chase a moving target when all you want to do is load some code...

Dec. 20, 2010

[Pharo-project] Issue 3468 in pharo: Perform and context frame size primitive tests

by pharo＠googlecode.com

Status: Fixed Owner: stephane.ducasse Labels: Milestone-1.3 New issue 3468 by stephane.ducasse: Perform and context frame size primitive tests http://code.google.com/p/pharo/issues/detail?id=3468 The perform: primitive reuses the context of the method calling it. The primitive adds performed selector arguments to the context variables list. So this means that you can execute some methods but not performed them if the calling methods defined too many temps. These tests pass on Cog but fails on squeak4.2.5 vm Attachments: CompiledMethodTest-tests - performing.st 2.0 KB

Dec. 20, 2010

Re: [Pharo-project] [squeak-dev] Re: Graph library in Smalltalk - Need for advices

by CÃ©drick BÃ©ler

>> >> Couldn't we start developing something similar to Lemon (regarding "API", enitites, etc...) that would work for small scale project project in smalltalk ? > > It would be excellent. > Because now that you have a full time permanent position you can invest a bit and in 2 years you can get something really sexy.... > This is what we are doing all the time around pharo. yes this is the idea :) have fun and learn... and I learn more when I do it by myself ;). I don't like blackboxes especially for research (we use netica here for bayesian networks). But again here, I can't do it alone (a generic small scale graph lib). I'll wait to have some feedback from others and see if a consensus arise for the design (the lib to mimic ?)... then I may start if I think I can (but I'll need review). Cheers, CÃ©drick

Dec. 20, 2010

[Pharo-project] What to do with the PharoOne click encoding ?? Fwd: Issue 3205 in pharo: monticello's error on Linux

by Mariano Martinez Peck

I noticed this problem several times also. I even remeber once I asked why the shell script was sending -encoding utf8 how we can fix it ? can we just ommit it ? what happens when we run a normal vm with a normal image? I guess we don't send any particular encoding there... cheers mariano ---------- Forwarded message ---------- From: <pharo(a)googlecode.com> Date: Mon, Dec 20, 2010 at 11:48 AM Subject: Re: [Pharo-project] Issue 3205 in pharo: monticello's error on Linux To: pharo-project(a)lists.gforge.inria.fr Comment #2 on issue 3205 by sanchezlsp: monticello's error on Linux http://code.google.com/p/pharo/issues/detail?id=3205 Thank you. That works.

Dec. 20, 2010

Re: [Pharo-project] Issue 2705 in pharo: Collection enh for Cog

by Marcus Denker

On Dec 20, 2010, at 4:10 PM, Levente Uzonyi wrote: > On Mon, 20 Dec 2010, pharo(a)googlecode.com wrote: > >> >> Comment #5 on issue 2705 by marcus.denker: Collection enh for Cog >> http://code.google.com/p/pharo/issues/detail?id=2705 >> >> I will add just copyUpThrough: >> >> > > #fold: is sent by the Cog VMMaker code, so you either implement it, modify the Cog VMMaker code or you won't be able to build a Cog from a Pharo image (building such an image is a tedious task anyway). We will encounter (and fix) these things when we do the VM auto-build setup. Maybe we then just load a pre-load for things like that. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Dec. 20, 2010

Re: [Pharo-project] Issue 3410 in pharo: Remove NEwInspector from Dev

by pharo＠googlecode.com

Comment #4 on issue 3410 by marcus.denker: Remove NEwInspector from Dev http://code.google.com/p/pharo/issues/detail?id=3410 Issue 2247 has been merged into this issue.

Dec. 20, 2010

Re: [Pharo-project] Dear Santa ...

by CÃ©drick BÃ©ler

A global Information System for Smalltalk, a system directed towards smalltalk projects and **people** (I mean smalltalkers whether dev or user) :). Ideally directed towards all smalltalk flavors (because more than the code, design discussions, algorithms are the most valuable information and this is just too sparse now) but that could be just Pharo/Squeak as a start, or even just Pharo to avoid too much hassle... I might not be really clear below but here's what I'd love as a central repository/system for smalltalkers (if Santa exists, he will understand me anyway ;o) ). This system will be before all oriented towards community, people, developpers so people can discuss design, see the profile of other smalltalkers, have an overall view on a project, its state, what people think about, etc etc... We need a better VISIBILITY on the existing (projects and people), and retrieval according to our taste... We need to characterize projets and above all people (that's the difficult point because this could led to offensive remarks. We should think a lot on how to objectively characterize developpers and then projects to stay polite and nice) Here are some examples of the kind of mechanisms I'd like in such a tool: (1) I like a lot Mr. R. developing style. Far more professional than what I can do, so I trust his project if I need to reuse. For some people, this might be too much engineered (any resemblance to persons living or programming in smalltalk is purely coincidental ). Anyway, I **trust** his projects and what he thinks on others. So I'd like to get the appropriate feedback (ie. what are the projects he cares about). (2) Mr C. has a similar profile as me, so I'm "automatically" interested in what he does and what he thinks (comments, discussion), etc... (3) Automatic discovery and notifications on "pieces of interest" -> project, dicussions, etc... (for instance, I'm not that interested right now in VM stuffs...) To me, it's just a discussion on how to characterize a project and a smalltalker (I don't say it's easy), then how to compare them (I can help there - on comparison on fuzzy entities). All the rest is UI and Tool stuffs. ***One simple subset and starting point would be to have a simple web page by smalltalkers*** Each user/developper will be automatically registered on that system (be the page be private by default) This page (url - maybe just the fragment) could be the unique identifier of the developer. No more initials, or combination of names, instead we have a classic login/password. Then it could be the entry point for a larger system... why not in squeaksource 2 ? Thanks Santa, I hope you get the idea :) YAD CÃ©drick (Yet Another Dreamer) ps: to finish some random thoughts: -Organised by projets -- project (code + comments by other + vote + blog) -- platforms (backup for legacy ones - ex: works for squeak 3.8, so we keep a **working** one click version somewhere) -- documentation (for a specific version) - again blog + interactive documentation (video associated to specific versions, **list of Deubug It methods in certain context***) -- code indicators (number of...) -- code (bleeding) + RC versions (+comments from others) (metacello ? only pharo... metametacello :) ) - dependancies... -- have a clear "time scale" of the project (when started, when released, still developped...) -Organized by people/group --profile/group description, interest, ... --automatic mailing list for groups --all projects done, even just started

Dec. 20, 2010

Re: [Pharo-project] Issue 2705 in pharo: Collection enh for Cog

by Levente Uzonyi

On Mon, 20 Dec 2010, pharo(a)googlecode.com wrote: > > Comment #5 on issue 2705 by marcus.denker: Collection enh for Cog > http://code.google.com/p/pharo/issues/detail?id=2705 > > I will add just copyUpThrough: > > #fold: is sent by the Cog VMMaker code, so you either implement it, modify the Cog VMMaker code or you won't be able to build a Cog from a Pharo image (building such an image is a tedious task anyway). Levente

Dec. 20, 2010