April 2017 - Pharo-users - lists.pharo.org

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

Re: [Pharo-users] Brisbane

by Offray Vladimir Luna CÃ¡rdenas

Hi Jeff, Congrats for this initiative. We are creating a local group here in Colombia, mainly in our Hackerspace [1] (Universities here have forgotten about Pharo/Smalltalk an are incredible bureaucratic and slow). Our approach involves data storytelling and agile visualization, with a particular emphasis on data activism. Some details of it are on [2] and the memories (in Spanish) in [3][4], because we have a local first approach. I'm slowly creating English content, like the main page [5], a new user manual[6] and intro pages for the projects repositories[7][8]. [1] http://hackbo.co/ [2] https://pharoweekly.wordpress.com/2016/10/26/about-alternate-ways-to-teach-… [3] http://mutabit.com/dataweek/ [4] http://mutabit.com/repos.fossil/dataweek/ [5] http://mutabit.com/grafoscopio/index.en.html [6] http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Manual/ma… [7] http://mutabit.com/repos.fossil/grafoscopio/ [8] http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Packages/Dataviz/intro.… Sharing our experience and approaches can help in the consolidation of our local groups. So I hope this helps, and let us know how things are going with your meetup. Cheers, Offray On 06/04/17 19:34, Jeff Gray 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

Brisbane

by Jeff Gray

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

Re: [Pharo-users] Voyage and attributes references

by Norbert Hartl

> Am 06.04.2017 um 18:41 schrieb Hilaire <hilaire(a)drgeo.eu>: > > Le 06/04/2017 Ã 16:14, Norbert Hartl a Ã©crit : >>> One idea will be to have collection of Address, but this really looks >>> strange to me. >>> >> why? >> > > It looks like a painful scenario: Address is most of the time referenced > by only one object, but in one scenario I need a shared attributes. > Because of this it implies to overlook for #save and #remove messages to > Address instances all around, forgetting some leading to bugs. But there > are not alternative I guess? Or to have two Address class, one set as a > root. Not sure what is the best practice. > Not sure either. But I think having a SharedAddress class is worth a try. The other possibility would be if #voyageRoot would be also instance side. Right now I don't have a computer to check. Norbert > Hilaire > > -- > Dr. Geo > http://drgeo.eu > >

April 6, 2017

Re: [Pharo-users] Voyage and attributes references

by Hilaire

Le 06/04/2017 Ã 16:14, Norbert Hartl a Ã©crit : >> One idea will be to have collection of Address, but this really looks >> strange to me. >> > why? > It looks like a painful scenario: Address is most of the time referenced by only one object, but in one scenario I need a shared attributes. Because of this it implies to overlook for #save and #remove messages to Address instances all around, forgetting some leading to bugs. But there are not alternative I guess? Or to have two Address class, one set as a root. Not sure what is the best practice. Hilaire -- Dr. Geo http://drgeo.eu

April 6, 2017