- Pharo-dev - lists.pharo.org

Re: [Pharo-project] PHARO_VM on Jenkins
by Marcus Denker May 10, 2012

May 10, 2012

On May 10, 2012, at 2:23 PM, Pavel Krivanek wrote: > Hi, > > I got this error on Pharo Kernel 2.0 Jenkins build: > PHARO_VM environment variable is not set. > > Did somebody some VM related changes on Jenkins? Yes, Christoph is setting up a mechanism that switches automatically to the last compiled (and successfully tested) VM for all jenkins... Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] student project: a simple recognizer
by stephane ducasse May 10, 2012

May 10, 2012

Hi guys Here is a topic for somebody that would like to have fun with events. There is a javascript version and it would be cool to have a version for Pharo. http://depts.washington.edu/aimgroup/proj/dollar/ http://www.lifl.fr/~casiez/PJE/OneDollar.pdf It is probably close to Genie but at least the algorithms are clearly defined. Stef

1 0

[Pharo-project] [update 2.0] #20064
by Marcus Denker May 10, 2012

May 10, 2012

20064 ----- Issue 5838: Error: Could not access http://www.squeaksource.com/MetaRepoForPharo20 http://code.google.com/p/pharo/issues/detail?id=5838 Issue 5806: Add an encrypted mode on PluggableTextFieldMorph http://code.google.com/p/pharo/issues/detail?id=5806 Issue 5712: Do the Icons need attribution? http://code.google.com/p/pharo/issues/detail?id=5712 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] Fwd: Do you know any candidates for assistant positions in our department
by StÃ©phane Ducasse May 10, 2012

May 10, 2012

Begin forwarded message: > From: Kim Mens <Kim.Mens(a)uclouvain.be> > Subject: Do you know any candidates for assistant positions in our department > Date: May 10, 2012 10:28:45 AM GMT+02:00 > To: researchers RELEASED <released(a)listes.uclouvain.be> > > Dear all, > > I am urgently looking for possible candidates to fill up some teaching and research assistants in our department. Such an assistant typically has teaching and research duties and gets up to 6 years to obtain a PhD (to be renewed every 2 years). The 6 years is because of the extra teaching load as compared to a normal researchers. Regarding research, they get to choose what professor they want to do research with and negotiate the research topic with him; evidently I'm open to have them under my guidance, but the choice is up to them. Regarding teaching, the teaching charges are distributed equally among the different assistants based on their capacities and interests. The positions are very interesting, and they get a real contract and fair salary (as compared to some other countries). A university level degree of master in computer science or computing science engineering (or something equivalent) is a must. (For foreigners, equivalence of their diploma will need to be verified but that can be done afterwards I think.) Knowledge of French is strongly desired because the bachelor years are still taught in French and we are already quite short on French-speaking researchers to help out with teaching duties in the bachelor years. Knowledge of English is also positive since our Master years are taught in English. Anyway, if you would know anyone, please pass them this information. The deadline is very short since all forms need to be filled in and submitted electronically by May 18, which would mean they need to start working on it right now. A internal selection commission of professors from our department will select the three best candidates from all those who applied. > > More instructions on how to apply can be found here : > http://www.uclouvain.be/11617.html > The candidate needs to fill out the digital form that is available there. If they click on "Listes des postes vacants" they will see the different vacancies currently available for the entire university. The ones related to our department can be found under the faculty "Ecole Polytechnique de Louvain" and more specifically the vacancies with identification numbers 00001941, 00002203, en 00004257. > You will see that 2 of these 3 have a description that is particularly dedicated to computer science. The third one looks more general, but in fact it has been decided recently that it will also go to computer science, but we weren't able to change the description anymore. Interested candidates should thus fill in the form and are strongly advised to apply to each of the 3 positions, even though they can receive only one. (I agree the procedure is a bit absurd, but what did you expect, this is Belgium.) > > Of course you can always contact me for more information or if the procedure is not 100% clear (even though I also had to look all of this up on the official university webpage). > > That's it for now... > > Thanks for your attention to this mail. > > Prof. Kim Mens > UniversitÃ© catholique de Louvain (UCL) > Institute of Information & Communication Technologies, Electronics and Applied Mathematics (ICTEAM) > IngÃ©nierie Informatique (INGI) > Place Sainte Barbe 2, B-1348 Louvain-la-Neuve, Belgique > kim.mens(a)uclouvain.be > > >

2 1

[Pharo-project] [update 2.0] #20063
by Marcus Denker May 10, 2012

May 10, 2012

20063 ----- Issue 5852: remove NepaleseEnvironment http://code.google.com/p/pharo/issues/detail?id=5852 Issue 5312: Move/Deprecate StandardFileStream browserRequest protocol http://code.google.com/p/pharo/issues/detail?id=5312 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] Redirecting Transcript
by Sean P. DeNigris May 10, 2012

May 10, 2012

There were several list threads about redirecting the Transcript e.g. to stdout... Is this available now in Pharo? If so, how do I redirect it to stdout? Thanks. Sean -- View this message in context: http://forum.world.st/Redirecting-Transcript-tp4622373.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 3

[Pharo-project] SimpleLiteralArrayParser
by stephane ducasse May 10, 2012

May 10, 2012

Hi guys We should develop a simple Literal Array parser that is dialect independant so that we can avoid using JSON for meta data. So I will start to develop. I will start to write some tests and do it test first. Gofer new repository: 'http://ss3.gemstone.com/ss/SimpleLiteralArrayParser'; package: 'SimpleLiteralArrayParser'; load Now I still wonder what do we do about floats. May be the situation changed but Squeak and VW floats were not the same. Stef

6 9

Re: [Pharo-project] tentative schedule for the pharo conference
by Marcus Denker May 10, 2012

May 10, 2012

On May 9, 2012, at 11:23 PM, Francisco Garau wrote: > Hi Stef - there is one hour difference between the iCal and HTML versions. this is because you are in england? > > It starts at 9am, correct? > yes. > - Francisco > > On 9 May 2012 12:20, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > Hi guys > > Here is a tentative schedule for the forth coming conference. > > ICAL: > https://www.google.com/calendar/ical/2d97rjlqso704v09d49sgcsjec%40group.cal… > > HTML: > https://www.google.com/calendar/embed?src=2d97rjlqso704v09d49sgcsjec%40grou… > > > please lets us know if you have any idea feedback. > -- > > Sef > > <Screen shot 2012-05-09 at 22.19.52.png> -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] FFI in Fedora
by Casimiro de Almeida Barreto May 10, 2012

May 10, 2012

On 09-05-2012 19:25, Schwab,Wilhelm K wrote: > Even on Ubuntu, the library search is broken. I've had to create > symlinks in the vm directory to get Cog to see much of anything. Are > you using callbacks? I tried them, with some success, but ultimately > went back to using a C/C++ .so to export needed functions. The > callbacks were "working" and I could step through them with the > debugger ( very encouraging and useful!!!!), but ultimately I would > get one of a couple of downstream errors after the callback activity > was over, or so it seemed. > > Is your image crashing as part of this? > > > > ------------------------------------------------------------------------ > *I tried both ways with native (pre-compiled VMs) and VMs that I compiled myself. Native CogVM fails but won't crash. The same with native SqueakVM (traditional VM). CogVM won't compile 64bit mode. SqueakVM compiles 64bit mode and then is capable of calling /usr/lib64 stuff. But most stuff will crash due to problems with pointer sizes. I've got crashes like: *bash-4.2$ LD_LIBRARY_PATH=/usr/lib/nvidia:/usr/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH bash-4.2$ /usr/local/lib/squeak/*/squeakvm Segmentation fault 36490628 OpenGL>beginFrame 36490536 OGLUnixX11LE>beginFrame 36488076 OpenGL class>example 36487984 BlockClosure>ensure: 36418764 OpenGL class>example 36418672 UndefinedObject>? 35844976 Compiler>evaluate:in:to:notifying:ifFail:logged: 35846456 TextEditor>evaluateSelectionAndDo: 35846364 BlockClosure>on:do: 35846272 TextEditor>evaluateSelectionAndDo: 35846180 TextEditor>evaluateSelection 35846088 PluggableTextMorph>doIt 35845952 TextMorph>handleEdit: 35845736 PluggableTextMorph>handleEdit: 35845644 PluggableTextMorph>doIt 35845528 StringHolder>perform:orSendTo: 35845412 MenuItemMorph>invokeWithEvent: 35845320 BlockClosure>ensure: 35845228 Cursor>showWhile: 35844776 MenuItemMorph>invokeWithEvent: 35844684 MenuItemMorph>mouseUp: 35844592 MenuItemMorph>handleMouseUp: 35844460 MouseButtonEvent>sentTo: 35844368 Morph>handleEvent: 35844276 MorphicEventDispatcher>dispatchDefault:with: 35844184 MorphicEventDispatcher>dispatchEvent:with: 35844092 Morph>processEvent:using: 35844000 MorphicEventDispatcher>dispatchDefault:with: 35843892 MorphicEventDispatcher>dispatchEvent:with: 35843760 Morph>processEvent:using: 35843668 Morph>processEvent: 35843576 MenuMorph>handleFocusEvent: 35843484 HandMorph>sendFocusEvent:to:clear: 35843328 BlockClosure>on:do: 35843236 PasteUpMorph>becomeActiveDuring: 35843116 HandMorph>sendFocusEvent:to:clear: 35843024 HandMorph>sendEvent:focus:clear: 35842932 HandMorph>sendMouseEvent: 35842788 HandMorph>handleEvent: 35842444 HandMorph>processEvents 35842352 WorldState>doOneCycleNowFor: 35842260 SequenceableCollection>do: 35842168 WorldState>handsDo: 35842076 WorldState>doOneCycleNowFor: 35841892 WorldState>doOneCycleFor: 35841800 WorldState>doOneSubCycleFor: 35841708 PasteUpMorph>doOneSubCycle 35821636 MenuMorph>invokeModalAt:in:allowKeyboard: 35821544 MenuMorph>invokeModal: 35821440 MenuMorph>invokeModal 35814024 PluggableTextMorph>yellowButtonActivity: 35813932 ScrollPane>mouseDown: 35813840 Morph>handleMouseDown: 35813748 MouseButtonEvent>sentTo: 35813656 Morph>handleEvent: 35813484 MorphicEventDispatcher>dispatchMouseDown:with: 35813392 MorphicEventDispatcher>dispatchEvent:with: 35813300 Morph>processEvent:using: 35813168 MorphicEventDispatcher>dispatchMouseDown:with: 35813076 MorphicEventDispatcher>dispatchEvent:with: 35812984 Morph>processEvent:using: 35812892 MorphicEventDispatcher>dispatchMouseDown:with: 35812800 MorphicEventDispatcher>dispatchEvent:with: 35812692 Morph>processEvent:using: 35812600 PasteUpMorph>processEvent:using: 35812488 Morph>processEvent: 35812396 HandMorph>sendEvent:focus:clear: 35812304 HandMorph>sendMouseEvent: 35812160 HandMorph>handleEvent: 35812000 HandMorph>processEvents 35811908 WorldState>doOneCycleNowFor: 35811816 SequenceableCollection>do: 35811724 WorldState>handsDo: 35811632 WorldState>doOneCycleNowFor: 35811540 WorldState>doOneCycleFor: 35811448 PasteUpMorph>doOneCycle 31204620 Project class>spawnNewProcess 31201020 BlockClosure>newProcess* But it was expected since it was a 64bit VM pointing to 32bit libraries... When LD_LIBRARY_PATH is left unchanged, then it won't crash and it won't load libraries. *

1 0

[Pharo-project] Help reading dump?
by Schwab,Wilhelm K May 10, 2012

May 10, 2012

The attached is diagnostic output from the Linux vm. I am doing some iterative numerical analysis that won't always work out, so I expect errors and non-sense results at times - it all depends on whether a particular segment of a signal is clean or noisy; if the latter, all assumptions are off. One thought is that early terminated iterations (or maybe ones that go too long?) are leaving conditions that finalization can't clean, or maybe does not clean before the next iteration begins. A segmentation fault seems a bit harsh, but they are happening and I need to find a way around them. Is there anything in the attached dump that strikes you as significant? Maybe something that says whether its the main thread or a background thread that's blowing up, or some other clue that is obvious to the correct eye? As it is, I see the #iterate, #basicIterate part of the stack, which is what I would expect the code to be trying to do - fit curves to data. The numbers at the beginning are trace info (using C++ cout) to confirm sanity of the arriving parameters. My next thought is to add some more tracing to show which segment/harmonic is being attacked as it blows up. Then I might be able to set clever breakpoints and get some handle on it. Suggestions are welcome. Bill

2 2