- Pharo-dev - lists.pharo.org

[Pharo-project] VM crash on update
by Milan Mimica Jan. 4, 2012

Jan. 4, 2012

Hello! I can quite easily crash the VM when updating pharo 1.4 image (Right click -> System -> Software Update). It crashes almost always. VM is Cog r2522. (gdb) bt #0 markAndTrace (oop=-7168) at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:20994 #1 0x080602c2 in markAndTraceStackPage (thePage=0xffffaa8c) at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:20887 #2 0x0806036d in markAndTraceStackPages (fullGCFlag=<value optimized out>) at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:20777 #3 markAndTraceInterpreterOops (fullGCFlag=<value optimized out>) at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:20648 #4 0x080746b1 in markPhase (fullGCFlag=-2139637670) at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:21333 #5 0x08074d3e in incrementalGC () at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:17530 #6 0x080751ff in sufficientSpaceAfterGC (minFree=-2139637670) at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:43517 #7 0x08078081 in checkForEventsMayContextSwitch (mayContextSwitch=1) at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:11257 #8 0x0807a6e0 in ceCheckForInterrupts () at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:10012 #9 0xb79886eb in ?? () #10 0x08082164 in initStackPagesAndInterpret () at /home/eliot/oscogvm/src/vm/gcc3x-cointerp.c:18088 #11 0x0805c49a in main (argc=Cannot access memory at address 0x8077b85a ) at /home/eliot/oscogvm/platforms/unix/vm/sqUnixMain.c:1769 -- Milan Mimica http://sparklet.sf.net

3 2

[Pharo-project] roadmap
by Tudor Girba Jan. 4, 2012

Jan. 4, 2012

Hi, Lukas and Stefan (Marr) both raised the topic of the roadmap. From Lukas: > This leads me to the question: Did anybody ever sketch an architecture > of where Pharo should be heading to? I created a simplified one based > on my own understanding of the current proposals: http://bit.ly/vpnAf1 > (Google Docs). I think too that they have a point. Stef answered: > We should because we know where we want to go. I think that at the very least it is a communication issue. From outside it is unclear in what order should the efforts be spent. We have a ton of wishes, but not an understanding of where we want to get and how. Please, let's discuss this roadmap. Not listing wishes, but actionable points. I start with some questions: - beside RB and Announcements, are there other things that could be problematic - how do we approach the RB problem? Is it Ok to get it out of the image and have Jenkins build the Pharo distribution by loading the head? Cheers, Doru -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

6 10

[Pharo-project] glamour and pharo
by Tudor Girba Jan. 4, 2012

Jan. 4, 2012

Hi, Let's take this on the Pharo mailing list. I do think that Glamour should be considered for being part of the Pharo infrastructure. At least the Core and the basic Morphic rendering (i.e., without Mondrian, EyeSee and Magritte). And I also think your analysis is not accurate. Here is why (I apologize for the long list): 1. Glamour is quite well documented. There is a chapter describing it. There are a tone of examples documenting all sorts of features. There comments are not as good as they could be, but there are comments, and I can help documenting more. 2. It is quite well tested. This part can be improved, but the core has some 80% coverage. 3. I am not the only one that knows how to mingle with it. To give some examples, Jorge, Damien (Cassou) and Esteban helped fixing some intricate bugs directly in the core. Lukas built the first Seaside rendering quite fast. I would also mention that as a student, Andrei Chis took about 1 month of work to produce a working version of a Seaside rendering almost from scratch. So, maybe it's not that difficult. 4. The core is quite stable since more than 1 year. There were changes, but they were mostly related to bug fixes. 5. The main point of using this infrastructure is not to replace Morphic, but it is to limit the maintenance of the browsers, and to empower more people to build more browsers. For example, the Glamorous Inspector has less than 200 lines of code in total. This is really tiny for the amount of things it offers. And it is highly extensible, too. 6. It's actually not that large: the core has 36 classes, and if you consider all the other presentations, helper classes and specialized browsers (but without the rendering code), you get some 93 classes. 7. But, perhaps the most important part is that there have been literally hundreds of browsers built on top of it. Not all of them are useful now, but they were when they were built. And it seems that people can build one quite fast without much knowledge of the internals either. That is the whole point of this infrastructure. Esteban even used it for building commercial applications. I built a couple, too. The whole of Moose is now using this infrastructure, too. I am not saying that Glamour is perfect. There are quite a couple of things I would like to enhance (for example, the request ideas from Omnibrowser, or the wizard workflows from Merlin), but it has proved to be quite solid until now. So, before dismissing Glamour, perhaps it would be useful to actually look into it. Cheers, Doru > On Dec 31, 2011, at 1:00 PM, Tudor Girba wrote: > >> Hi Stef, >> >> You seem to say that it is bad that Glamour provides a good infrastructure that appeals to people. Maybe a better conclusion is that Glamour is something to be considered for the infrastructure of Pharo. > > Do you think so? > I do not think that we can base our infrastructure on something that only one person understand and can modify. > You will tell that this is the same for Morphic but this is not true. > > Stef > -- www.tudorgirba.com "Beauty is where we see it."

9 38

[Pharo-project] Keyboard navigation and Settings browser
by Sean P. DeNigris Jan. 4, 2012

Jan. 4, 2012

A few observations inspired by using the Settings browser: * Is there a way to exclude a submorph from tabbing? In the settings browser, if you keep tabbing, you eventually focus on the statusView, which is a text editor, and you start inserting tabs into the text instead of continuing to navigate * a disabled text editor should pass keyboard focus on tab instead of doing nothing (the current behavior) * how do you say which is the default widget? just set the keyboard focus manually? This would be hard using the Polymorph workflow as in the examples/Pharocasts/etc. because: - you'd have to store a reference to the morph instance, so you can set the focus after the window has been opened (will not work otherwise). - tools like the Settings browser build the UI in an instance method, so now a morph would have to be stored in the model - yuck Dialog window has #defaultFocusMorph. Maybe this should be added to SystemWindow? * EditableDropListMorphs should pass keyboard focus to their contentMorph. Right now it takes two tabs to activate. The first one just highlights the EditableDropListMorph, but does not let you type into it What do you think? Sean p.s. this exploration started because I thought it'd be more useful if the Settings browser opened with the search field active -- View this message in context: http://forum.world.st/Keyboard-navigation-and-Settings-browser-tp4258311p42… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 2

[Pharo-project] Monticello trickery: pointers needed
by Frank Shearar Jan. 4, 2012

Jan. 4, 2012

Hi, The background to the question is that I'm trying to repackage LanguageBoxes so that both the Squeak and Pharo community can use its features (or just parts of it). Cutie-Helvetia defines a class, CURaisedToExample. Among others, it defines two methods: CURaisedToExample class >> #raise:to and CURaisedToExample >> testSplice. The latter makes use of QQCompiler's splice operation (just like Common Lisp's) - @foo will replace 'foo' with whatever 'foo' evaluates to, so compiling 'a := @(3 + 4)' means the same thing as 'a := 7'. Now testSplice says self assert: `@(self raise: 2 to: -3) = (1/8). which means that, _at_compile_time_, testSplice will invoke #raise:to: (the self refers to the class-side method)... and at this point in time #raise:to: has been compiled, but not installed. Compiling #testSplice fails with a MessageNotUnderstood, and package loading aborts. My question is this: how can I work around this? Can I move the installation of #raise:to: to a preload step? Some hacks that spring to mind, and don't seem very pleasant, are: * introduce a new superclass defining the method, put that in a seperate package, and load that package before Cutie-Helvetia * move the definition of CURaisedToExample and #raise:to: to a separate package, and make all the tests extensions to that package. frank

1 1

[Pharo-project] TWM Bug - different world menu
by Sean P. DeNigris Jan. 4, 2012

Jan. 4, 2012

When I access the world menu through the TWM bar, some of the items I have registered do not show up. Maybe items added after TWM was loaded do not show up. Anyone else notice this? Sean -- View this message in context: http://forum.world.st/TWM-Bug-different-world-menu-tp4244649p4244649.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 2

[Pharo-project] Bug Report: 6 of 6: Settings
by S Krish Jan. 4, 2012

Jan. 4, 2012

6. Settings: On Ubuntu Linux and on Windows: Go to the Network node and change the values for HTTP Proxy/ Proxy Authentication and quit and comeback.. Does not retain the settings.. ******************** Also .. I add it here.. though disconnected from the above.. but for Settings issue.. Sound Package: Well this one set of hack throughs to get it working on Linux.. Straight after loading the packages: Settings tab does not show up the 3+ lines of setting on loading the SoundSetting package.. Fails on Phenome** method not being initialized.. Go hack and comment some places in the code it starts to work beautifully thereafter.. will try and reap/ move hacks to more usable code and submit..

5 8

[Pharo-project] Call for papers - Science of Computer Programming: Special Issue on "Advances in Dynamic Languages"
by jannik.laval Jan. 3, 2012

Jan. 3, 2012

================================================ Special issue on "Advances in Dynamic Languages" ================================================ Special issue of Elsevier's Science of Computer Programming (SCICO) Context ------- Over recent years we have seen an increased interest in dynamic programming languages such as Smalltalk, Lisp, Scheme, PHP, JavaScript, Self, Python, Ruby, and so on. These languages have taken a prominent role in teaching, web development, scripting, rapid prototyping, tool building, language engineering, and many other domains. For this special issue we invite high-quality papers that focus on novel research related to dynamic programming languages and applications of these languages. We are interested in research that uses dynamic languages in the context of, but not restricted to: - Aspects, aspect Languages and applications. - Ambient intelligence, ubiquitous / pervasive computing and embedded systems. - Compilation technology, optimization, virtual machines. - Language engineering, extensions. - Model-driven engineering / development. - Meta-modeling, reflection and meta-programming. - Programming in the large; design, architectures and components. - Programming environments, browsers, user interfaces, UI frameworks. - Source-code analysis and manipulation (static analysis,refactoring, type inference, metrics). - Testing, eXtreme Programming / practices. - Web services, internet applications, event-driven programming. - Experience reports. The special issue is associated with the Smalltalks 2011 conference. The Smalltalks series of conferences (www.fast.org.ar) is a lively forum on Smalltalk-based software technologies that brings together more than 200 people from both academia and industry for a period of three days. Submission Guidelines --------------------- Papers should be written in English, in PDF-format and should not exceed 25 pages (including references and figures), using the Elsevier journal format. The LaTeX template for this format can be found at http://www.elsevier.com/wps/find/authorsview.authors/latex Papers must be submitted through the EES submission system located at http://ees.elsevier.com/scico/default.asp When reaching the "Article type" step in the submission process, it is important to select "Special issue: Advances in Dynamic Languages". Each paper will be reviewed by at least 3 experts within the domain. The accepted papers will be published in a special edition of Elsevier's Science of Computer Programming. Papers submitted must not have been previously published (at least 30% new material) and must not be under review for publication elsewhere. Papers must strictly adhere to submission guidelines. If you have questions, please send an e-mail to Jannik Laval (jlaval(a)labri.fr) and Andy Kellens (akellens(a)vub.ac.be) Important dates (tentitavely) ----------------------------- - Submission round 1: March 16, 2012 - Feedback round 1: May 17, 2012 - Submission round 2: June 29, 2012 - Feedback round 2 (final notification): August 17, 2012 - Camera ready version: September 14, 2012 Guest editors ------------- Andy Kellens (Vrije Universiteit Brussel, Belgium) Jannik Laval (LaBRI Bordeaux, France)

1 0

[Pharo-project] Category to be ignored by Monticello?
by Dave Mason Jan. 3, 2012

Jan. 3, 2012

I have some code that generates code on the fly in user classes. I want them to stay in the image for efficiency reasons, but if the user class gets saved in Monticello, I don't want the generated code saved. I can obviously put the methods in some particular category - say *auto*generated*do*not*save*. But after looking at Monticello for a bit, I can't find where it decides what to save - if, for example, it ignores things in other categories. Any help appreciated - either "Yes, it ignores *foo*bar* category", or "Here's where to look in Monticello" Thanks ../Dave

2 1

Jan. 3, 2012

we will have to check if this impacts some of our parameter handling. Stef Begin forwarded message: > VM.r2518/. > > CogVM binaries as per VMMaker.oscog-eem.139/r2518. > > Add access to VM arguments to Mac. Make Windows, Mac and Unix consistent: > Smalltalk getSystemAttribute: > -1 => executable name > -2 .. -n => VM arguments *including* image (if explicitly supplied). > Replace win32 command line parsing with unixesque code using CommandLineToArgvW. > > linux launch script: > Cope with old linuxes use of /lib/tls hack for an optional thread-local-storage > version of libc/libpthread. The launch scripts add /lib/tls:/usr/lib/tls: to > LD_LIBRARY_PATH instead of /lib:/usr/lib: if the VM is linked to /lib/tls/libc. > -- > best, > Eliot >

10 18