- Pharo-users - lists.pharo.org

Re: [Pharo-users] Adding our local hackerspace to Pharo Teachers page

by marcus.denker＠inrira.fr

Hi, I added it to http://pharo.org/Teachers <http://pharo.org/Teachers> -- Marcus Denker -- denker(a)acm.org <mailto:denker@acm.org> http://www.marcusdenker.de <http://www.marcusdenker.de/> > On 7 Apr 2017, at 17:55, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > >> HackBo, Hackerspace en BogotÃ¡, Colombia. http://hackbo.co/ <http://hackbo.co/>

April 7, 2017

Re: [Pharo-users] Adding our local hackerspace to Pharo Teachers page

by Offray Vladimir Luna CÃ¡rdenas

Hi, Bump!... Anyone? Offray On 24/12/16 13:11, Offray Vladimir Luna CÃ¡rdenas wrote: > Hi :-), > > We're teaching/learning Pharo in a consistent fashion in our local > hackerspace, HackBo in BogotÃ¡, Colombia. Could you please add this > line to the Pharo Teachers page: > > HackBo, Hackerspace en BogotÃ¡, Colombia. http://hackbo.co/ > > Thanks, > > Offray > > >

April 7, 2017

Re: [Pharo-users] Brisbane

by Stephane Ducasse

super! Let us know how we can help. On Fri, Apr 7, 2017 at 2:34 AM, Jeff Gray <jeff(a)rogerthedog.com> wrote: > Hi all, > Just an update. I just attended my third Smalltalk meet-up in Brisbane. > It's a small group but hopefully we can grow as we gain momentum. > We are just now setting up our team and initial project in Smalltalk Hub. > > We are meeting once a month in a great little venue by the river with free > fast Wi-Fi and good cheap coffee. > > I have been just hacking in Pharo on my own for a while now. I am looking > forward to working in a team environment, adding some rigour to my testing > and sharing techniques and approaches. > > > > > -- > View this message in context: http://forum.world.st/ > Brisbane-tp4941489.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

April 7, 2017

How can I set the SmaccDebugParser in Moose

by Stephane Ducasse

Hi I found the SmaCCParserDebugger and I found the debug menu in the Smacc tool. Now I get a GT and byteCode debugger but I do not find a way to make the new debugger actif. Stef

April 7, 2017

Re: [Pharo-users] Pharo image freeze and "Alt-." has no effect

by Steven RÃ©mot

I'm on Linux (Ubuntu 15.10), and the output of pharo -v is: 5.0 #1 Wed May 4 11:54:28 CEST 2016 gcc 4.6.3 [Production Spur ITHB VM] CoInterpreter VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 https://github.com/pharo-project/pharo-vm.git Commit: b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux plugin path: /home/steven/Documents/Programmes/pharo5.0/bin [default: /home/steven/Documents/Programmes/pharo5.0/bin/] Le ven. 7 avr. 2017 Ã 12:54, Alistair Grant <akgrant0710(a)gmail.com> a Ã©crit : > Hi Steven, > > Can you tell us which platform you're on, and the output of pharo --version > > Cheers, > Alistair > > > On 7 Apr. 2017 12:48, "Steven RÃ©mot" <steven.remot(a)gmail.com> wrote: > > Hello everyone, > > I'm new to pharo, and was writing a simple 2D game with Athens for > rendering to practice a bit. I'm loving the environment so far, developing > the game while it's running is really enjoyable :-) . > > However, when the game is running, the pharo image will freeze at a random > time. Alt-. doesn't make my image back to normal, the only solution I found > is closing my image and opening it again, until the next freeze... > > I don't really know what to do to investigate this bug, there is no output > from pharo about this. The only thing I thought about is starting from a > fresh image, importing my code and running it again to ensure it wasn't > some messy state in the image I was using, and it froze even when running > my code from a fresh image. > > What can I do to debug it? Do you need more information to give me a > direction? > > Just in case you need it, here is the source: > https://www.dropbox.com/s/pfn7ccw27i4nqr7/Creakout-debug.st?dl=0 > > Thanks, > Steven RÃ©mot > > >

April 7, 2017

Re: [Pharo-users] Pharo image freeze and "Alt-." has no effect

by Alistair Grant

Hi Steven, Can you tell us which platform you're on, and the output of pharo --version Cheers, Alistair On 7 Apr. 2017 12:48, "Steven RÃ©mot" <steven.remot(a)gmail.com> wrote: Hello everyone, I'm new to pharo, and was writing a simple 2D game with Athens for rendering to practice a bit. I'm loving the environment so far, developing the game while it's running is really enjoyable :-) . However, when the game is running, the pharo image will freeze at a random time. Alt-. doesn't make my image back to normal, the only solution I found is closing my image and opening it again, until the next freeze... I don't really know what to do to investigate this bug, there is no output from pharo about this. The only thing I thought about is starting from a fresh image, importing my code and running it again to ensure it wasn't some messy state in the image I was using, and it froze even when running my code from a fresh image. What can I do to debug it? Do you need more information to give me a direction? Just in case you need it, here is the source: https://www.dropbox.com/s/ pfn7ccw27i4nqr7/Creakout-debug.st?dl=0 Thanks, Steven RÃ©mot

April 7, 2017

Pharo image freeze and "Alt-." has no effect

by Steven RÃ©mot

Hello everyone, I'm new to pharo, and was writing a simple 2D game with Athens for rendering to practice a bit. I'm loving the environment so far, developing the game while it's running is really enjoyable :-) . However, when the game is running, the pharo image will freeze at a random time. Alt-. doesn't make my image back to normal, the only solution I found is closing my image and opening it again, until the next freeze... I don't really know what to do to investigate this bug, there is no output from pharo about this. The only thing I thought about is starting from a fresh image, importing my code and running it again to ensure it wasn't some messy state in the image I was using, and it froze even when running my code from a fresh image. What can I do to debug it? Do you need more information to give me a direction? Just in case you need it, here is the source: https://www.dropbox.com/s/pfn7ccw27i4nqr7/Creakout-debug.st?dl=0 Thanks, Steven RÃ©mot

April 7, 2017

Re: [Pharo-users] FileReference / and parent

by Denis Kudriashov

Hi Alistair. Do you open the issue? I found that it was already exist. Look at 13217 <https://pharo.fogbugz.com/f/cases/13217/FS-basename-with-compound-path-stri…> 2017-04-04 16:59 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > Hi Stef, > > On Tue, Apr 04, 2017 at 04:33:56PM +0200, Stephane Ducasse wrote: > > Hi alistair > > > > We should target Pharo 70. > > Yep, I saw Esteban's message saying he hopes 6.0 is only a week away, so > this can definitely wait. > > > > Now it is great that you help improving the file frameworks. > > Could you open a bug entry? > > Yep, I was just waiting to see if there was lots of resistance to these > changes (which there doesn't seem to be). > > > > Do you have tests? > > I was working on them when this email arrived. :-) > > I expect it will take me a week to get them to the point I'm happy (this > is a part time hobby), but they'll definitely be part of the slice / > pull request when I submit it. > > Cheers, > Alistair > > > > > > Stef > > > > On Mon, Apr 3, 2017 at 2:04 PM, Alistair Grant <akgrant0710(a)gmail.com> > > wrote: > > > > > Hi All, > > > > > > I previously suggested a change to Path>>/ which actually covered two > > > issues: > > > > > > 1. The handling of the parent directory notation, i.e. ".." > > > 2. The construction of path segments when appending a string. > > > > > > As Damien pointed out, the first issue needs a bit more consideration. > > > > > > I think the second point is still problematic and can be addressed > > > separately. In particular: > > > > > > ('/a/b/c' asFileReference / 'd/e/f') parent "File @ /a/b/c" > > > > > > I would expect the result to be "File @ /a/b/c/d/e" > > > > > > The fix is straightforward (although someone may be able to propose a > > > more elgant solution): > > > > > > -- > > > / aString > > > | path additionalPath index | > > > > > > aString isEmptyOrNil > > > ifTrue: [ Error signal: 'Path element cannot be empty > or > > > nil']. > > > > > > additionalPath := Path from: aString. > > > path := self class new: self size + additionalPath size. > > > path copyFrom: self. > > > index := self size + 1. > > > additionalPath do: [ :each | > > > path at: index put: each. > > > index := index + 1. > > > ]. > > > ^ path > > > -- > > > > > > 1. Do you agree with the proposed change? > > > 2. (Assuming you agree): Should we target Pharo 6.0 or 7.0? > > > On one side, this is clearly a bug, on the other, no one has > reported > > > it to date, so it isn't having a big impact. > > > > > > Thanks, > > > Alistair > > > > > > > >

April 7, 2017

Re: [Pharo-users] using UFFI in non-crashing way

by Denis Kudriashov

2017-04-07 8:22 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > But then the problem is on "how to not lose your code", not in FFI... >> >> >> Restarting image is a problem. For any other "smalltalk" problems we got >> suitable debugger but not in that case. > > > Also when image crashed we need to recover all objects state for the > script which produce crash > > > FFI is a border. > Once you start working with it, you are in C world. > And C world is nasty, hard and cumbersome. > Yes. And my remark was about possibility to catch C error to prevent image crash, why it will make FFI less hard.

April 7, 2017

Re: [Pharo-users] using UFFI in non-crashing way

by Esteban Lorenzano

> On 6 Apr 2017, at 10:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-04-06 10:37 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > But then the problem is on "how to not lose your code", not in FFI... > > Restarting image is a problem. For any other "smalltalk" problems we got suitable debugger but not in that case. > > Also when image crashed we need to recover all objects state for the script which produce crash FFI is a border. Once you start working with it, you are in C world. And C world is nasty, hard and cumbersome. In C world, pointers not correctly allocâd produce a crash. In C world, pointers not correctly freed also produce a crash, eventually (and those are harder to fix). In C world everything pointing to wrong location will produce a crash (and you can point anything to anywhere). Thatâs why garbage collectors were invented, after all. So my only advice here is: - recheck all your allocs/free, rigorously - save your image before test - be sure epicea is working Finally, I would say the only way to prevent your image to crash is to not execute FFI calls inside it. To do this, you can always use ImageWorker (http://smalltalkhub.com/#!/~PharoExtras/ImageWorker) to actually execute your tests in a different execution. Yes is slow, but it will be safer. Esteban

April 7, 2017