Re: [Pharo-dev] Possible PharoVM bug (wrong object on stack top)
I've opened a new issue for this bug: https://pharo.fogbugz.com/default.asp?11130 It has a couple of methods attached (together with their byte codes) that exhibited the problem. Cheers, Max On 27.06.2013, at 20:44, Igor Stasenko siguc...@gmail.com wrote: What i find fun with this bug, that it is one that is just annoying (you just get a DNU, then you restart and it works). Comparing to hard VM crash we experienced before... :) On 27 June 2013 20:23, p...@highoctane.be p...@highoctane.be wrote: I do have that issue often when loading my devstack configuration on Pharo 2.0 (as in http://www.smalltalkhub.com/#!/~philippeback/HOWebStack) Doing everything again fixes the problem but fingers crossed are required. It is a really annoying bug indeed. Phil --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:p...@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Featured on the Software Process and Measurement Cast http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Thu, Jun 27, 2013 at 3:22 PM, Igor Stasenko siguc...@gmail.com wrote: On 27 June 2013 14:13, Max Leske maxle...@gmail.com wrote: Hi I've been seeing a particular bug that I can only see when using the PharoVM and I was wondering if anybody else has been having the same issue. Under certain condition, a debugger will open displaying SmallInteger does not understand some message. The stack top contains an integer (something of the form 138402, not sure how many digits), which explains the message. However, the situation actually looks like this: htmil anchor id: 'foo'; … In this example, the error would be SmallInteger does not understand #id:. So the stack top contains an integer instead of the receiver. Restarting the execution of the method and proceeding fixes the problem. I think I've seen that (using seaside), a new session will trigger the bug again. Apart from Seaside, I've also seen the same problem when loading Roberto Minelli's DevFlow into a Pharo 2.0 image. The debugger will open on a Metacello method. VM: latest PharoVM image: latest 2.0 try this config: http://smalltalkhub.com/#!/~RobertoMinelli/DevFlow with ConfigurationOfDevFlow loadDevelopment Has anybody else encountered this? yes, couple months ago we had this issue. It looks like it doesn't likes some bytecode sequence (which causing this).. and this sequence is not appears that often. If i remember Esteban said that changing compiler optimizations flags fixed it.. but perhaps not on platform , you running on? Cheers, Max -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] We did it! SlotClassBuilder is active
Hehe, yes, and finally I can have more than 254 instance variables! Norbert Am 03.07.2013 um 23:38 schrieb Tudor Girba tu...@tudorgirba.com: Wow! I cannot wait to clunky dictionary-based instance variable extensions with slots. Doru On Wed, Jul 3, 2013 at 5:00 PM, Marcus Denker marcus.den...@inria.fr wrote: Hi, Today we turned on the SlotClassBuilder… this means actually quite a huge change, as it puts into place lots of things that we can build on later. What it means for now - A new, much easier to understand ClassBuilder - meta Objects. Layouts + Slots For example, there is now for every instance variable a meta object that describes it It will be very interesting to see what we can do with that! Thanks to Toon + Camillo for the original implementation, and Martin Dias with Camillo for the work to get in really into 3.0. Marcus -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] question about UI
This is just the start. I should go over it and integrate more based on the previous material and the videos that ben did. Stef On Jul 4, 2013, at 2:04 AM, Pablo R. Digonzelli pdigonze...@softsargentina.com wrote: !! Ing. Pablo Digonzelli Sofware Solutions IP Soluciones SRL 25 de Mayo 521. Entrepiso A email: pdigonze...@softsargentina.com email: pdigonze...@gmail.com twitter: @pdigonzelli Tel: 0381 4227378 Cel: 0381 155982714 De: Stéphane Ducasse stephane.duca...@inria.fr Para: Pharo Development List pharo-dev@lists.pharo.org Enviados: Miércoles, 3 de Julio 2013 17:30:24 Asunto: Re: [Pharo-dev] question about UI ;) Stef On Jul 3, 2013, at 9:44 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We should turn this blog into a chapter and merge it with the current tutorial. Gisela I can do a first cut and flesh a chapter in gutenberg :) Stef On Jul 3, 2013, at 8:54 AM, Gisela Decuzzi giseladecu...@gmail.com wrote: Hi Pablo, a few days ago I wrote about implementing a simple window with spec here: http://pharorwrules.wordpress.com/2013/06/26/a-look-into-spec/ 2013/7/3 Pablo R. Digonzelli pdigonze...@softsargentina.com Thanks to all! I starting learn spec Ing. Pablo Digonzelli Sofware Solutions IP Soluciones SRL 25 de Mayo 521. Entrepiso A email: pdigonze...@softsargentina.com email: pdigonze...@gmail.com twitter: @pdigonzelli Tel: 0381 4227378 Cel: 0381 155982714 De: Esteban Lorenzano esteba...@gmail.com Para: Pharo Development List pharo-dev@lists.pharo.org Enviados: Martes, 2 de Julio 2013 18:37:57 Asunto: Re: [Pharo-dev] question about UI On Jul 2, 2013, at 10:25 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: hello list. I am thinking develop a business application in pharo. Excellent! I need information about tools for UI for business applications. for example dolphin has MVP framework for desktop. Yes and its MVP framework is cool. I prefer browser/desktop enable UI framework. Which are the tools you can recommend? You should have a look at Spec - ben I do not remember where is the tutorial. Benjamin started to rewrite widgets like list. Perhaps someone has experience with businnes app. Esteban, benjamin. What I suggest is to really ask for feedback in the mailing-list and to be prepared to help also because we are changing the widgets and the tools (and the underlying layers but our time is short). I made a commercial desktop application using glamour+magritte+home made stuff nowadays, you could do more or less the same using spec/glamour+magritte3+keychain... it requires some work (mostly on learning any of them), but is perfectly doable :) Esteban TIA PD: Sorry for my english :) Frankly this is not important. Ing. Pablo Digonzelli Sofware Solutions IP Soluciones SRL 25 de Mayo 521. Entrepiso A email: pdigonze...@softsargentina.com email: pdigonze...@gmail.com twitter: @pdigonzelli Tel: 0381 4227378 Cel: 0381 155982714
Re: [Pharo-dev] We did it! SlotClassBuilder is active
On Jul 3, 2013, at 11:38 PM, Tudor Girba tu...@tudorgirba.com wrote: Wow! I cannot wait to clunky dictionary-based instance variable extensions with slots. Me too :) Imagine no more MorphExtension :) Stef
[Pharo-dev] [update 3.0] #30251
30251 - 2302 sorted and sorted: should be moved to TSortable https://pharo.fogbugz.com/f/cases/2302 (The image will have two dirty packages after this, we will fix that with the next update) Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Traits-MarcusDenker.15.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Sequenceable-MarcusDenker.138.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Abstract-MarcusDenker.213.diff
Re: [Pharo-dev] We did it! SlotClassBuilder is active
On Jul 4, 2013, at 10:47 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Jul 3, 2013, at 11:38 PM, Tudor Girba tu...@tudorgirba.com wrote: Wow! I cannot wait to clunky dictionary-based instance variable extensions with slots. Me too :) Imagine no more MorphExtension :) Indeed. And all the flags of morphic (sticky, locked…) would be stored in one SmallInteger. Marcus
Re: [Pharo-dev] We did it! SlotClassBuilder is active
Great! Time to simplify Magritte. Stephan
Re: [Pharo-dev] question about UI
Depending on your actual needs, you might get a much faster start by using Glamour. It allows building an application at a higher abstraction level. Stephan
Re: [Pharo-dev] We did it! SlotClassBuilder is active
I forgot about this side-effect. PetitParser will be so happy. Doru On Thu, Jul 4, 2013 at 9:51 AM, Norbert Hartl norb...@hartl.name wrote: Hehe, yes, and finally I can have more than 254 instance variables! Norbert Am 03.07.2013 um 23:38 schrieb Tudor Girba tu...@tudorgirba.com: Wow! I cannot wait to clunky dictionary-based instance variable extensions with slots. Doru On Wed, Jul 3, 2013 at 5:00 PM, Marcus Denker marcus.den...@inria.frwrote: Hi, Today we turned on the SlotClassBuilder… this means actually quite a huge change, as it puts into place lots of things that we can build on later. What it means for now - A new, much easier to understand ClassBuilder - meta Objects. Layouts + Slots For example, there is now for every instance variable a meta object that describes it It will be very interesting to see what we can do with that! Thanks to Toon + Camillo for the original implementation, and Martin Dias with Camillo for the work to get in really into 3.0. Marcus -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] We did it! SlotClassBuilder is active
And Moose :) Doru On Thu, Jul 4, 2013 at 10:56 AM, Stephan Eggermont step...@stack.nl wrote: Great! Time to simplify Magritte. Stephan -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] We did it! SlotClassBuilder is active
Thanks Martin for polishing everything :) It's ok! It was a lot of fun. Thanks also to Guille Polito, who helped writing tests during GSoC-2012. +1 for the blog post. I don't have too much to say of the plans for the future but I could write about the current state of the project. Martín
[Pharo-dev] [Warning] SmalltalkHub, Pharo association and Pharo consortium websites down
Hi! All our services (including backup servers) are currently down due to power issues with ERDF at our datacenter (you can follow it on twitter) https://twitter.com/online_fr/ They were running on a generator power for some time, but it seem to have finally failed too. All their support lines are busy, and we can't reach them by email either. I'm doing my best to resolve the issue as soon as possible, they promised us that the power would be back in 20'. I'm really sorry for the inconvenience. Cheers, Nico
Re: [Pharo-dev] NativeBoost with no access to sources
On 3 July 2013 23:04, GOUBIER Thierry thierry.goub...@cea.fr wrote: Hi Stephane, I worked around it... as long as I don't make FileReferenceexists as a NB call, then the Changes file will open correctly and NB calls will work after that (Changes opening doesn't use isReadable or isWriteable, which is interesting in itself ;))... But it makes my solution fragile. However, if you make the Changes file not readable (still owned by you, still writeable), many interesting things happen, starting with a nbGetEnv failure and a total unability to quit Pharo apart from a killall pharo. I tried to: - Get NB to accept positional arguments instead of named ones (by catching names like _1, _2). Easy, since apparently the NB generated code just takes an offset on the pointer stack finally (i.e. names are only used to get the index in the arguments array). Seemed to work. can you share this code? i think it doesn't hurts being able to refer to method argument by number , not by name, if author wants to. - Change all NB calls with numbers above to be able to have NB working before / without the Changes file. Ended with a segfault on startup (globalSymbolLoading for GetEnv again), and I gave up. Igor, would there be a way to write the call with the effective arguments instead of #symbols, so that by looking at the bytecode you would get the position in the arguments stack? Or would it be possible to store by hand the source of the methods (triggered by the pragma) inside a source cache inside NB for the time being? Or is there an event for NB correct start (with Changes and all ready) so that we can write NB code with a fallback if NB isn't able to work? i wanna change it, so that when you compile method with NB primitive, it remembers the arg names. NB made it so easy to do simple and usefull calls to external libs that I really want it to work! Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Stéphane Ducasse [stephane.duca...@inria.fr] Date d'envoi : mercredi 3 juillet 2013 21:51 À : Pharo Development List Objet : Re: [Pharo-dev] NativeBoost with no access to sources I don't know.. look: realloc: flags mem: lpMem size: dwBytes primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode ^ self nbCall: #( LPVOID HeapReAlloc (self, DWORD flags, LPVOID lpMem, SIZE_T dwBytes) ) here, see: flags, lpMem, dwBytes names is in function signature same as in your method. That's how NB knows which argument from method corresponds to argument passed to function. now if you don't use argument names , how the above should look like? realloc: flags mem: lpMem size: dwBytes primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode ^ self nbCall: #( LPVOID HeapReAlloc (self, DWORD @1, LPVOID @2, SIZE_T @3) ) ? Igor I understand your concerns but also the problem thierry is facing and it looks to me like a valid scenario. Stef -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
On 3 July 2013 22:36, Guillermo Polito guillermopol...@gmail.com wrote: I'm just guessing, but if a function receives a pointer, it does not store the pointer anywhere but works with the contents, and finally returns while VM is blocked, voilá :). Yes. On Wed, Jul 3, 2013 at 10:13 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: if you pass a pointer to something in object memory into function, make sure GC cannot move the object while function uses/accessing its contents. How? -- Best regards, Igor Stasenko.
[Pharo-dev] All websites are back online!
We got the power back :) I recovered the databases for all 3 websites, and restarted them. Cheers, Nico On Jul 4, 2013, at 11:47 AM, Nicolas Petton petton.nico...@gmail.com wrote: Hi! All our services (including backup servers) are currently down due to power issues with ERDF at our datacenter (you can follow it on twitter) https://twitter.com/online_fr/ They were running on a generator power for some time, but it seem to have finally failed too. All their support lines are busy, and we can't reach them by email either. I'm doing my best to resolve the issue as soon as possible, they promised us that the power would be back in 20'. I'm really sorry for the inconvenience. Cheers, Nico -- Nicolas Petton http://www.nicolas-petton.fr
Re: [Pharo-dev] We did it! SlotClassBuilder is active
On Thu, Jul 4, 2013 at 11:17 AM, Martin Dias tinchod...@gmail.com wrote: +1 for the blog post. I don't have too much to say of the plans for the future but I could write about the current state of the project. yes please, current state description is already great. You may want to write it in Pier format so that we get a nice chapter. -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] All websites are back online!
Cool :) Congratulation for your reactivity :) Ben On Jul 4, 2013, at 12:08 PM, Nicolas Petton petton.nico...@gmail.com wrote: We got the power back :) I recovered the databases for all 3 websites, and restarted them. Cheers, Nico On Jul 4, 2013, at 11:47 AM, Nicolas Petton petton.nico...@gmail.com wrote: Hi! All our services (including backup servers) are currently down due to power issues with ERDF at our datacenter (you can follow it on twitter) https://twitter.com/online_fr/ They were running on a generator power for some time, but it seem to have finally failed too. All their support lines are busy, and we can't reach them by email either. I'm doing my best to resolve the issue as soon as possible, they promised us that the power would be back in 20'. I'm really sorry for the inconvenience. Cheers, Nico -- Nicolas Petton http://www.nicolas-petton.fr
Re: [Pharo-dev] [rmod] All websites are back online!
thanks a lot :) On 2013-07-04, at 12:08, Nicolas Petton petton.nico...@gmail.com wrote: We got the power back :) I recovered the databases for all 3 websites, and restarted them. Cheers, Nico On Jul 4, 2013, at 11:47 AM, Nicolas Petton petton.nico...@gmail.com wrote: Hi! All our services (including backup servers) are currently down due to power issues with ERDF at our datacenter (you can follow it on twitter) https://twitter.com/online_fr/ They were running on a generator power for some time, but it seem to have finally failed too. All their support lines are busy, and we can't reach them by email either. I'm doing my best to resolve the issue as soon as possible, they promised us that the power would be back in 20'. I'm really sorry for the inconvenience. Cheers, Nico -- Nicolas Petton http://www.nicolas-petton.fr
Re: [Pharo-dev] All websites are back online!
On Thu, Jul 4, 2013 at 12:11 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: Cool :) Congratulation for your reactivity :) +1 Ben On Jul 4, 2013, at 12:08 PM, Nicolas Petton petton.nico...@gmail.com wrote: We got the power back :) I recovered the databases for all 3 websites, and restarted them. Cheers, Nico On Jul 4, 2013, at 11:47 AM, Nicolas Petton petton.nico...@gmail.com wrote: Hi! All our services (including backup servers) are currently down due to power issues with ERDF at our datacenter (you can follow it on twitter) https://twitter.com/online_fr/ They were running on a generator power for some time, but it seem to have finally failed too. All their support lines are busy, and we can't reach them by email either. I'm doing my best to resolve the issue as soon as possible, they promised us that the power would be back in 20'. I'm really sorry for the inconvenience. Cheers, Nico -- Nicolas Petton http://www.nicolas-petton.fr
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
ok we should write that in the NB chapter. On Jul 3, 2013, at 10:36 PM, Guillermo Polito guillermopol...@gmail.com wrote: I'm just guessing, but if a function receives a pointer, it does not store the pointer anywhere but works with the contents, and finally returns while VM is blocked, voilá :). On Wed, Jul 3, 2013 at 10:13 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: if you pass a pointer to something in object memory into function, make sure GC cannot move the object while function uses/accessing its contents. How?
Re: [Pharo-dev] All websites are back online!
+1 On Thu, Jul 4, 2013 at 12:23 PM, Usman Bhatti usman.bha...@gmail.com wrote: On Thu, Jul 4, 2013 at 12:11 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: Cool :) Congratulation for your reactivity :) +1 Ben On Jul 4, 2013, at 12:08 PM, Nicolas Petton petton.nico...@gmail.com wrote: We got the power back :) I recovered the databases for all 3 websites, and restarted them. Cheers, Nico On Jul 4, 2013, at 11:47 AM, Nicolas Petton petton.nico...@gmail.com wrote: Hi! All our services (including backup servers) are currently down due to power issues with ERDF at our datacenter (you can follow it on twitter) https://twitter.com/online_fr/ They were running on a generator power for some time, but it seem to have finally failed too. All their support lines are busy, and we can't reach them by email either. I'm doing my best to resolve the issue as soon as possible, they promised us that the power would be back in 20'. I'm really sorry for the inconvenience. Cheers, Nico -- Nicolas Petton http://www.nicolas-petton.fr
[Pharo-dev] Abbreviations
Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community: in Pharo 3.0 one can write: Smalltalk os env or would it be better to use: Smalltalk operatingSystem environment in the future? So is the current Smalltalk vm better than Smalltalk virtualMachine I know: even a newcomer should know what OS means. At least Smalltalkers/Java people should know they need a VM. But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible. Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API GetEnvironmentVariableA which does not use abbreviations) Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms? Or will we keep abbreviations for the lazy and easier typing? If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ...
Re: [Pharo-dev] Abbreviations
I agree wholeheartedly! I still believe in (mostly) self documenting code and that cannot be achieved by using abbreviations. Max On 04.07.2013, at 12:52, Torsten Bergmann asta...@gmx.de wrote: Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community: in Pharo 3.0 one can write: Smalltalk os env or would it be better to use: Smalltalk operatingSystem environment in the future? So is the current Smalltalk vm better than Smalltalk virtualMachine I know: even a newcomer should know what OS means. At least Smalltalkers/Java people should know they need a VM. But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible. Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API GetEnvironmentVariableA which does not use abbreviations) Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms? Or will we keep abbreviations for the lazy and easier typing? If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ...
Re: [Pharo-dev] NativeBoost with no access to sources
Le 04/07/2013 11:58, Igor Stasenko a écrit : On 3 July 2013 23:04, GOUBIER Thierry thierry.goub...@cea.fr wrote: Hi Stephane, I worked around it... as long as I don't make FileReferenceexists as a NB call, then the Changes file will open correctly and NB calls will work after that (Changes opening doesn't use isReadable or isWriteable, which is interesting in itself ;))... But it makes my solution fragile. However, if you make the Changes file not readable (still owned by you, still writeable), many interesting things happen, starting with a nbGetEnv failure and a total unability to quit Pharo apart from a killall pharo. I tried to: - Get NB to accept positional arguments instead of named ones (by catching names like _1, _2). Easy, since apparently the NB generated code just takes an offset on the pointer stack finally (i.e. names are only used to get the index in the arguments array). Seemed to work. can you share this code? i think it doesn't hurts being able to refer to method argument by number , not by name, if author wants to. I wondered if it could be both (name and number), but went for the shortest path, that is the simplest solution: NBFFICalloutloaderFromMethodArgsNamed: argName methodArgs ifNotNil: [ | index | (argName first = $_ and: [ argName allButFirst isAllDigits ]) ifTrue: [ ^ NBSTMethodArgument new stackIndex: methodArgs size - argName asUnsignedInteger ]. index := methodArgs indexOf: argName ifAbsent: [ nil ]. index ifNotNil: [ ok, this is a method argument ^ NBSTMethodArgument new stackIndex: methodArgs size - index ] ]. ^ nil Then I tried to change all calls to use numbers, but it ended in a Segfault (not in NB itself, but somewhere else as if I had a corrupted heap). The end result with all changes is there: http://ss3.gemstone.com/ss/PharoInbox/SLICE-Issue-11102-FileSystemError-Path--root-ThierryGoubier.4.mcz If you see where I missed something, I'd be happy to know. - Change all NB calls with numbers above to be able to have NB working before / without the Changes file. Ended with a segfault on startup (globalSymbolLoading for GetEnv again), and I gave up. Igor, would there be a way to write the call with the effective arguments instead of #symbols, so that by looking at the bytecode you would get the position in the arguments stack? Or would it be possible to store by hand the source of the methods (triggered by the pragma) inside a source cache inside NB for the time being? Or is there an event for NB correct start (with Changes and all ready) so that we can write NB code with a fallback if NB isn't able to work? i wanna change it, so that when you compile method with NB primitive, it remembers the arg names. Yes, I suspect it would be the best solution. Trap on primitive: ? If you track the MethodAdded / MethodRemoved events, you can note all uses of primitive: and cache the info there ? NB made it so easy to do simple and usefull calls to external libs that I really want it to work! Thierry De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Stéphane Ducasse [stephane.duca...@inria.fr] Date d'envoi : mercredi 3 juillet 2013 21:51 À : Pharo Development List Objet : Re: [Pharo-dev] NativeBoost with no access to sources I don't know.. look: realloc: flags mem: lpMem size: dwBytes primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode ^ self nbCall: #( LPVOID HeapReAlloc (self, DWORD flags, LPVOID lpMem, SIZE_T dwBytes) ) here, see: flags, lpMem, dwBytes names is in function signature same as in your method. That's how NB knows which argument from method corresponds to argument passed to function. now if you don't use argument names , how the above should look like? realloc: flags mem: lpMem size: dwBytes primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode ^ self nbCall: #( LPVOID HeapReAlloc (self, DWORD @1, LPVOID @2, SIZE_T @3) ) ? Igor I understand your concerns but also the problem thierry is facing and it looks to me like a valid scenario. Stef -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] Abbreviations
+1000 On Thu, Jul 4, 2013 at 12:57 PM, Max Leske maxle...@gmail.com wrote: I agree wholeheartedly! I still believe in (mostly) self documenting code and that cannot be achieved by using abbreviations. Max On 04.07.2013, at 12:52, Torsten Bergmann asta...@gmx.de wrote: Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community: in Pharo 3.0 one can write: Smalltalk os env or would it be better to use: Smalltalk operatingSystem environment in the future? So is the current Smalltalk vm better than Smalltalk virtualMachine I know: even a newcomer should know what OS means. At least Smalltalkers/Java people should know they need a VM. But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible. Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API GetEnvironmentVariableA which does not use abbreviations) Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms? Or will we keep abbreviations for the lazy and easier typing? If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ... -- Cheers,
Re: [Pharo-dev] Abbreviations
+ One Norbert Am 04.07.2013 um 12:52 schrieb Torsten Bergmann asta...@gmx.de: Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community: in Pharo 3.0 one can write: Smalltalk os env or would it be better to use: Smalltalk operatingSystem environment in the future? So is the current Smalltalk vm better than Smalltalk virtualMachine I know: even a newcomer should know what OS means. At least Smalltalkers/Java people should know they need a VM. But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible. Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API GetEnvironmentVariableA which does not use abbreviations) Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms? Or will we keep abbreviations for the lazy and easier typing? If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ...
Re: [Pharo-dev] Abbreviations
On Jul 4, 2013, at 12:52 , Torsten Bergmann wrote: Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community: in Pharo 3.0 one can write: Smalltalk os env or would it be better to use: Smalltalk operatingSystem environment in the future? So is the current Smalltalk vm better than Smalltalk virtualMachine I know: even a newcomer should know what OS means. At least Smalltalkers/Java people should know they need a VM. But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible. Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API GetEnvironmentVariableA which does not use abbreviations) Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms? Or will we keep abbreviations for the lazy and easier typing? If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ... My 2c: Acronyms work fine, also in method names. (os, vm) As a basic rule require to spell out ante meridiem, light amplification by stimulated emission of radiation, radio detection and ranging, compact disk, and their likes, seems a bit … zealous. Simple abbreviations, like env, rather than using the full word, I have much less empathy for. Cheers, Henry
Re: [Pharo-dev] Abbreviations
Am 04.07.2013 um 13:09 schrieb Henrik Johansen henrik.s.johan...@veloxit.no: On Jul 4, 2013, at 12:52 , Torsten Bergmann wrote: Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community: in Pharo 3.0 one can write: Smalltalk os env or would it be better to use: Smalltalk operatingSystem environment in the future? So is the current Smalltalk vm better than Smalltalk virtualMachine I know: even a newcomer should know what OS means. At least Smalltalkers/Java people should know they need a VM. But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible. Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API GetEnvironmentVariableA which does not use abbreviations) Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms? Or will we keep abbreviations for the lazy and easier typing? If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ... My 2c: Acronyms work fine, also in method names. (os, vm) As a basic rule require to spell out ante meridiem, light amplification by stimulated emission of radiation, radio detection and ranging, compact disk, and their likes, seems a bit … zealous. Simple abbreviations, like env, rather than using the full word, I have much less empathy for. I like to avoid abbreviations as much as possible. But you are right when it comes to use very common ones I don't have a strong feeling about. To me I think vm and os are widely used so there is nothing to decipher in order to be able to understand it. The selector env I find not commonly used ( I know it mostly from console usage ). And there is Behavior#environment which I feel is inconsistent. Norbert
Re: [Pharo-dev] Abbreviations
On 04.07.2013, at 13:09, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On Jul 4, 2013, at 12:52 , Torsten Bergmann wrote: Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community: in Pharo 3.0 one can write: Smalltalk os env or would it be better to use: Smalltalk operatingSystem environment in the future? So is the current Smalltalk vm better than Smalltalk virtualMachine I know: even a newcomer should know what OS means. At least Smalltalkers/Java people should know they need a VM. But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible. Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API GetEnvironmentVariableA which does not use abbreviations) Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms? Or will we keep abbreviations for the lazy and easier typing? If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ... My 2c: Acronyms work fine, also in method names. (os, vm) As a basic rule require to spell out ante meridiem, light amplification by stimulated emission of radiation, radio detection and ranging, compact disk, and their likes, seems a bit … zealous. Agreed. There are conventional terms that can (and maybe should) be abbreviated. But in general I'm against abbreviations. Simple abbreviations, like env, rather than using the full word, I have much less empathy for. Cheers, Henry
[Pharo-dev] R: Abbreviations
+1 -Messaggio originale- Da: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] Per conto di Max Leske Inviato: giovedì 4 luglio 2013 12:58 A: Pharo Development List Oggetto: Re: [Pharo-dev] Abbreviations I agree wholeheartedly! I still believe in (mostly) self documenting code and that cannot be achieved by using abbreviations. Max On 04.07.2013, at 12:52, Torsten Bergmann asta...@gmx.de wrote: Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community: in Pharo 3.0 one can write: Smalltalk os env or would it be better to use: Smalltalk operatingSystem environment in the future? So is the current Smalltalk vm better than Smalltalk virtualMachine I know: even a newcomer should know what OS means. At least Smalltalkers/Java people should know they need a VM. But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible. Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API GetEnvironmentVariableA which does not use abbreviations) Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms? Or will we keep abbreviations for the lazy and easier typing? If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ...
Re: [Pharo-dev] Abbreviations
On 2013-07-04, at 12:52, Torsten Bergmann asta...@gmx.de wrote: Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community: in Pharo 3.0 one can write: Smalltalk os env actually that #env there is more complicated than you think :) - `Smalltalk os` returns OSPlatform, the class - implementing #environment on the class side will break the compiler for this class My first attempt was of course to use #environment as a name, which failed horribly ;) So first we have to complete the refactoring that `Smalltalk os` returns an instance of OSPlatform. Only then we can move to #environment, which by looking at #OSEnvironment is the intended name. So all in all you detected the symptoms of a much worse problem, using class-sides instead of instances. In any case, I agree that #env is not nice at all...
[Pharo-dev] [update 3.0] #30253
30253 - 10936 Athens update (was: As yet unclassified) https://pharo.fogbugz.com/f/cases/10936 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-Morphic-MarcusDenker.19.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-Core-MarcusDenker.33.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-CairoPools-MarcusDenker.7.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-Cairo-MarcusDenker.44.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-Balloon-MarcusDenker.11.diff
Re: [Pharo-dev] We did it! SlotClassBuilder is active
Congrats!! This opens more doors to me since i we can have stateful traits now :) 2013/7/4 Damien Cassou damien.cas...@gmail.com On Thu, Jul 4, 2013 at 11:17 AM, Martin Dias tinchod...@gmail.com wrote: +1 for the blog post. I don't have too much to say of the plans for the future but I could write about the current state of the project. yes please, current state description is already great. You may want to write it in Pier format so that we get a nice chapter. -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
[Pharo-dev] utf8 in mcz (SmalltalkHub)
Has someone seen something happening with Monticello Mcz handling extended characters ? If I add a non-ascii character to MCMockClassA comment, such as ø, then MCMczInstallerTesttestInstallFromFile fails. If I add an ascii character instead to MCMockClassA comment, then this test pass. (On 2.0 / 20610) It's recent and has appeared between mid-june and now. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
[Pharo-dev] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=linux-stable-worker/316/ 1 regressions found. Tests.Release.ReleaseTest.testUndeclared
[Pharo-dev] [update 3.0] #30254
30254 - 7492 Convert MetacelloConfigurationBrowser to Spec https://pharo.fogbugz.com/f/cases/7492 11056 Traits in _UnpackagedPackage https://pharo.fogbugz.com/f/cases/11056 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1168.diff
[Pharo-dev] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=mac/316/ 1 regressions found. Tests.Release.ReleaseTest.testUndeclared
[Pharo-dev] [update 3.0] #30255
30255 - 11078 preferences directory not properly set on Windows https://pharo.fogbugz.com/f/cases/11078 11129 Support compiler method class creation in new class builder https://pharo.fogbugz.com/f/cases/11129 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/SlotTests-MarcusDenker.38.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Slot-MarcusDenker.341.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-MarcusDenker.99.diff
Re: [Pharo-dev] utf8 in mcz (SmalltalkHub)
Hi Henrik, Thanks for the info; I effectively ended in setConverterForCode... One more reason to use github over Smalltalkhub: correct handling of accentuated text :( I'll do some testing to make sure I know how to safely copy github hosted packages to smalltalkhub, and avoid polluting my git repository. Thierry Le 04/07/2013 15:03, Henrik Johansen a écrit : On Jul 4, 2013, at 2:22 , Goubier Thierry wrote: Has someone seen something happening with Monticello Mcz handling extended characters ? If I add a non-ascii character to MCMockClassA comment, such as ø, then MCMczInstallerTesttestInstallFromFile fails. If I add an ascii character instead to MCMockClassA comment, then this test pass. (On 2.0 / 20610) It's recent and has appeared between mid-june and now. Thierry -- Not sure you can call it recent, the same bug exists and is reproduceable by adding an ø to MCMockClassA back to at least Pharo 1.0 :) It happens due to: MCZInstaller #installMember: member self useNewChangeSetDuring: [ | str |str := member contentStream text. *str setConverterForCode*. CodeImporter evaluateReadStream: str readStream. ] setConverterForCode has never been the right thing to do for reading non-ascii .st files written by Monticello, since it's tended to write the raw strings to disk without any regard to encoding. For the comment you modified, that means it would have been written as latin1, and attempted to be read as MacRoman, where the code point of ø is different. In recent 3.0 versions, it's been fixed by Nicolas Cellier's changes to actually store/read .st files created by Monticello in utf8. Cheers, Henry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Re: [Pharo-dev] [Moose-dev] SourceCity works
I updated the ConfigurationOfSourceCity. Gofer new smalltalkhubUser: 'ErwanDouaille' project: 'SourceCity'; configuration; load. ConfigurationOfSourceCity loadBleedingEdge 2013/6/10 Igor Stasenko siguc...@gmail.com On 10 June 2013 05:53, Alexandre Bergel alexandre.ber...@me.com wrote: Apparently, you have no idea what you talking about. Great communication skills :-) Yes, i felt offended. Because it exists for 2 years for now. And your just saying to people that it doesn't exists, just because you loaded wrong/outdated config. You could just search mailing list (dated back to 2010 when it was first released), before/instead of doing any conclusions. Because if i would miss this mail: you/your student would be just wasting precious time trying to make something which already exists. Now tell me, who should care more about your time, me or yourself? Open browser and look for NBOpenGL-X and NBXLib-Core packages. I have put Javier in CC since he would be very interesting in discovering that things he did does not exist :) When I evaluate NBGLContextDriver allSubclasses it returns: an OrderedCollection(NBMacGLContextDriver NBWin32GLContextDriver) Nothing wrong in thinking that there is no binding for Linux. Look, Alex... by analogy, i can download Squeak 3.9 image and state that Pharo doesn't exists on pharo mailing list... and nothing wrong in thinking that. What version you are using? NBGLContextDriver allSubclasses an OrderedCollection(NBMacGLContextDriver NBWin32GLContextDriver NBGLXContextDriver) When I was trying to make open gl working, I have seen ConfigurationOfNBXLib and the NBXLib* packages. http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL does not say a word what these packages are for. I can imagine NBOpenGL is to interact with OpenGL. Maybe NB stands for NativeBoost. But NBXLib no idea. Oh well... Maybe for the X-Server? But is this related to OpenGL? Yes it is related. Linux desktop uses X server, to initialize OpenGL context there you must create an X window first. For all 'maybes' , google has an answer: try googling 'opengl linux' click on 1st hit , and read linux section: Linux Graphics on Linux is almost exclusively implemented using the X windows system. Supporting OpenGL on Linux involves using GLX extensions to the X Server. Today I succeeded to make OpenGL running on my machine. Cool stuff! Thanks for this! Now imagine, that the problems you had to deal with, is a norm in C world for anything: missing dependencies, found it, but it doesn't compiles, compiled but it doesn't works, works but sometimes crashes etc etc. Cheers, Alexandre -- Best regards, Igor Stasenko. -- Best regards, Douaille Erwan douaille.er...@gmail.com
Re: [Pharo-dev] We did it! SlotClassBuilder is active
2013/7/4 Sebastian Tleye stl...@gmail.com Congrats!! This opens more doors to me since i we can have stateful traits now :) Indeed! 2013/7/4 Damien Cassou damien.cas...@gmail.com On Thu, Jul 4, 2013 at 11:17 AM, Martin Dias tinchod...@gmail.com wrote: +1 for the blog post. I don't have too much to say of the plans for the future but I could write about the current state of the project. yes please, current state description is already great. You may want to write it in Pier format so that we get a nice chapter. -- Damien Cassou http://damiencassou.seasidehosting.st Success is the ability to go from one failure to another without losing enthusiasm. Winston Churchill
Re: [Pharo-dev] Sunburst visualization
Very nice ! On 04 Jul 2013, at 15:20, Alexandre Bergel alexandre.ber...@me.com wrote: Hi! We are currently working on a Sunburst based on top of Roassal. Milton is doing a fantastic job! Here some early screenshots: image copy 2.pngimage copy.pngimage.png Milton Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] [Moose-dev] SourceCity works
https://ci.inria.fr/pharo-contribution/job/SourceCity/ done 2013/7/4 Camillo Bruni camillobr...@gmail.com On 2013-07-04, at 15:35, Erwan Douaille douailleer...@gmail.com wrote: I updated the ConfigurationOfSourceCity. Gofer new smalltalkhubUser: 'ErwanDouaille' project: 'SourceCity'; configuration; load. ConfigurationOfSourceCity loadBleedingEdge would it make sense to make a jenkins job for this? -- Best regards, Douaille Erwan douaille.er...@gmail.com
[Pharo-dev] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=mac/318/ 1 regressions found. Tests.CodeImport.ChunkImportTestCase.testImportAClassCategory
[Pharo-dev] [regression reporter]regression occurred
https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=win/319/ 1 regressions found. Tests.CodeImport.ChunkImportTestCase.testImportAClassCategory
Re: [Pharo-dev] [Moose-dev] SourceCity works
On 2013-07-04, at 16:47, Erwan Douaille douailleer...@gmail.com wrote: https://ci.inria.fr/pharo-contribution/job/SourceCity/ ;) nice
Re: [Pharo-dev] Roassal 3d is on its way
Nice to see that. The difficult part is usually the interaction. Yes, the interaction is the tricky part. Ronie is an OpenGL expert BTW JUn added 3DPoint so may be a good thing Yes! Alexandre One good news never come alone :-) We are working on a 3d version of Roassal. Here is a preliminary screenshot: Roassal3D.jpg More to come soon! Cheers, Ronie, Milton, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] Sunburst visualization
:) I'm happy With Athens a new space is opening :) Yes, Athens made it possible. Now do you handle interaction? All the interaction is handled by Roassal. Each piece of Arc has an announcer ... Alexandre On Jul 4, 2013, at 3:20 PM, Alexandre Bergel alexandre.ber...@me.com wrote: Hi! We are currently working on a Sunburst based on top of Roassal. Milton is doing a fantastic job! Here some early screenshots: image copy 2.pngimage copy.pngimage.png Milton Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] [Moose-dev] SourceCity works
thanks! Stef On Jul 4, 2013, at 5:22 PM, Camillo Bruni camillobr...@gmail.com wrote: On 2013-07-04, at 16:47, Erwan Douaille douailleer...@gmail.com wrote: https://ci.inria.fr/pharo-contribution/job/SourceCity/ ;) nice
[Pharo-dev] New Consortium Member: Debris Publishing
New Consortium Member: Debris Publishing The Pharo Consortium welcomes a new member company: Debris Publishing Inc. : http://debrispublishing.com Debris is joining as a Silver Member. More about... - Debris Publishing Inc.: http://debrispublishing.com - Pharo: http://pharo.org - Pharo Consortium: http://consortium.pharo.org
Re: [Pharo-dev] Sunburst visualization
Sunburst + Roassal3D = Burning Man style CodeCity? Looking good Peace! Stephan
Re: [Pharo-dev] Roassal 3d is on its way
Erwan wrote: My question is, why trying to make something which is already working ? I mean, just changing some SourceCity stuff and it will work for roassal (i guess). SourceCity is a fixed layout with buildings blocks. Roassal allows switching combining layouts. So yes, you should be able to do a codecity layout with Roassal 3D Stephan
Re: [Pharo-dev] [Moose-dev] Sunburst visualization
I would be happy to. But I forgot my login and password for http://association.pharo.org Who should I ask for this? Alexandre On Jul 4, 2013, at 11:36 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: alex you should publish that on the pharo association web site. On Jul 4, 2013, at 3:24 PM, Alexandre Bergel alexandre.ber...@me.com wrote: Hi! We are currently working on a Sunburst based on top of Roassal. Milton is doing a fantastic job! Here some early screenshots: https://www.facebook.com/photo.php?fbid=478025185617417set=a.341189379300999.82969.340543479365589type=1theater https://www.facebook.com/photo.php?fbid=478024745617461set=a.341189379300999.82969.340543479365589type=1theater Cheers, Milton Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] New Consortium Member: Debris Publishing
Cool! I am working for them and it is a very nice company! Thanks for supporting Pharo. On Thu, Jul 4, 2013 at 12:41 PM, Marcus Denker marcus.den...@inria.frwrote: New Consortium Member: Debris Publishing The Pharo Consortium welcomes a new member company: Debris Publishing Inc. : http://debrispublishing.com Debris is joining as a Silver Member. More about... - Debris Publishing Inc.: http://debrispublishing.com - Pharo: http://pharo.org - Pharo Consortium: http://consortium.pharo.org -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] [Moose-dev] SourceCity works
Hi Erwan and all, Just to make a few things clear about Roassal 3d vs SourceCity. We are currently working on Roassal 3d, which intends to be a nice layer at the top of NBOpenGL and NBXLib to easily create 3d scenes with cubes, lights, camera, interactions, zooming, translucent coloring, clicking/rotating/translating individual elements and so on. Everything that is good for Roassal is equally good for 3D Scene. Having a city-like visualization will be one of our first objectives since (i) it is a compelling use of 3D and (ii) it is easy to implement (at least the bases). We started to work on a CityBuilder, to easily create cities from objects and provided metrics. Ideally, it would be great to have SourceCity based on our effort. Not now since we have just started Roassal 3D, but on some point we should merge (this is similar in the 2d World with Mondrian and EyeSee moving from plain Morphic to Roassal). Our objective is to offer a great 3d framework to make a truly flying SourceCity. Does this make sense to you? Cheers, Alexandre On Jul 4, 2013, at 10:47 AM, Erwan Douaille douailleer...@gmail.com wrote: https://ci.inria.fr/pharo-contribution/job/SourceCity/ done 2013/7/4 Camillo Bruni camillobr...@gmail.com On 2013-07-04, at 15:35, Erwan Douaille douailleer...@gmail.com wrote: I updated the ConfigurationOfSourceCity. Gofer new smalltalkhubUser: 'ErwanDouaille' project: 'SourceCity'; configuration; load. ConfigurationOfSourceCity loadBleedingEdge would it make sense to make a jenkins job for this? -- Best regards, Douaille Erwan douaille.er...@gmail.com -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] NativeBoost with no access to sources
On 4 July 2013 13:07, Goubier Thierry thierry.goub...@cea.fr wrote: Le 04/07/2013 11:58, Igor Stasenko a écrit : On 3 July 2013 23:04, GOUBIER Thierry thierry.goub...@cea.fr wrote: Hi Stephane, I worked around it... as long as I don't make FileReferenceexists as a NB call, then the Changes file will open correctly and NB calls will work after that (Changes opening doesn't use isReadable or isWriteable, which is interesting in itself ;))... But it makes my solution fragile. However, if you make the Changes file not readable (still owned by you, still writeable), many interesting things happen, starting with a nbGetEnv failure and a total unability to quit Pharo apart from a killall pharo. I tried to: - Get NB to accept positional arguments instead of named ones (by catching names like _1, _2). Easy, since apparently the NB generated code just takes an offset on the pointer stack finally (i.e. names are only used to get the index in the arguments array). Seemed to work. can you share this code? i think it doesn't hurts being able to refer to method argument by number , not by name, if author wants to. I wondered if it could be both (name and number), but went for the shortest path, that is the simplest solution: NBFFICalloutloaderFromMethodArgsNamed: argName methodArgs ifNotNil: [ | index | (argName first = $_ and: [ argName allButFirst isAllDigits ]) ifTrue: [ ^ NBSTMethodArgument new stackIndex: methodArgs size - argName asUnsignedInteger ]. index := methodArgs indexOf: argName ifAbsent: [ nil ]. index ifNotNil: [ ok, this is a method argument ^ NBSTMethodArgument new stackIndex: methodArgs size - index ] ]. ^ nil This looks fine , and i will add it into NB. Then I tried to change all calls to use numbers, but it ended in a Segfault (not in NB itself, but somewhere else as if I had a corrupted heap). The end result with all changes is there: http://ss3.gemstone.com/ss/PharoInbox/SLICE-Issue-11102-FileSystemError-Path--root-ThierryGoubier.4.mcz If you see where I missed something, I'd be happy to know. you probably made a mistake somewhere. ;) because counting the argument index, instead of putting its name is error prone. - Change all NB calls with numbers above to be able to have NB working before / without the Changes file. Ended with a segfault on startup (globalSymbolLoading for GetEnv again), and I gave up. Igor, would there be a way to write the call with the effective arguments instead of #symbols, so that by looking at the bytecode you would get the position in the arguments stack? Or would it be possible to store by hand the source of the methods (triggered by the pragma) inside a source cache inside NB for the time being? Or is there an event for NB correct start (with Changes and all ready) so that we can write NB code with a fallback if NB isn't able to work? i wanna change it, so that when you compile method with NB primitive, it remembers the arg names. Yes, I suspect it would be the best solution. Trap on primitive: ? If you track the MethodAdded / MethodRemoved events, you can note all uses of primitive: and cache the info there ? not cache, just put it into method's attributes, so i can access them later. And not when method added/removed, but at compilation time. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [Moose-dev] Sunburst visualization
Cool. Low hanging fruits. We all love them :) -- Best regards, Igor Stasenko.
Re: [Pharo-dev] question about UI
Yes! Damien also told me to transform the post into a chapter. Thanks for starting :D I will take a look and finish it next week 2013/7/4 Stephan Eggermont step...@stack.nl Depending on your actual needs, you might get a much faster start by using Glamour. It allows building an application at a higher abstraction level. Stephan
Re: [Pharo-dev] Fwd: Artifacts on Linux using NBOpenGL
Hi, the NB XLib wrapper covers just the basic functionality. It was made just to prove that it's possible, but not extended much far. If you are using the examples provided, they probably fail when the window is closed because the event loop keeps calling XLib functions, passing the pointer to the window object that has already been destroyed. On Thu, Jul 4, 2013 at 2:17 PM, Erwan Douaille douailleer...@gmail.comwrote: HI ! I just updated the SourceCity configurationOf, using the latest version of NBOpenGL. It's running on Linux but i have many artifacts, i just report you that bug :) I also have 3 new empty window opened. And if i close them, image closing and i have this error message in shell. wawan@wawan-MS-16F1:~/Downloads/latest$ pharo Pharo-30252.image XIO: fatal IO error 4 (Interrupted system call) on X server :0 after 48 requests (48 known processed) with 1 events remaining. Thanks -- Lic. Javier Pimás Ciudad de Buenos Aires
Re: [Pharo-dev] Roassal 3d is on its way
+1 On Jul 4, 2013, at 12:00 PM, Stephan Eggermont step...@stack.nl wrote: Erwan wrote: My question is, why trying to make something which is already working ? I mean, just changing some SourceCity stuff and it will work for roassal (i guess). SourceCity is a fixed layout with buildings blocks. Roassal allows switching combining layouts. So yes, you should be able to do a codecity layout with Roassal 3D Stephan -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] Roassal 3d is on its way
Very nice. On Thu, Jul 4, 2013 at 8:50 PM, Alexandre Bergel alexandre.ber...@me.comwrote: +1 On Jul 4, 2013, at 12:00 PM, Stephan Eggermont step...@stack.nl wrote: Erwan wrote: My question is, why trying to make something which is already working ? I mean, just changing some SourceCity stuff and it will work for roassal (i guess). SourceCity is a fixed layout with buildings blocks. Roassal allows switching combining layouts. So yes, you should be able to do a codecity layout with Roassal 3D Stephan -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] [Moose-dev] SourceCity works
+1 Doru On Jul 4, 2013, at 6:23 PM, Alexandre Bergel alexandre.ber...@me.com wrote: Hi Erwan and all, Just to make a few things clear about Roassal 3d vs SourceCity. We are currently working on Roassal 3d, which intends to be a nice layer at the top of NBOpenGL and NBXLib to easily create 3d scenes with cubes, lights, camera, interactions, zooming, translucent coloring, clicking/rotating/translating individual elements and so on. Everything that is good for Roassal is equally good for 3D Scene. Having a city-like visualization will be one of our first objectives since (i) it is a compelling use of 3D and (ii) it is easy to implement (at least the bases). We started to work on a CityBuilder, to easily create cities from objects and provided metrics. Ideally, it would be great to have SourceCity based on our effort. Not now since we have just started Roassal 3D, but on some point we should merge (this is similar in the 2d World with Mondrian and EyeSee moving from plain Morphic to Roassal). Our objective is to offer a great 3d framework to make a truly flying SourceCity. Does this make sense to you? Cheers, Alexandre On Jul 4, 2013, at 10:47 AM, Erwan Douaille douailleer...@gmail.com wrote: https://ci.inria.fr/pharo-contribution/job/SourceCity/ done 2013/7/4 Camillo Bruni camillobr...@gmail.com On 2013-07-04, at 15:35, Erwan Douaille douailleer...@gmail.com wrote: I updated the ConfigurationOfSourceCity. Gofer new smalltalkhubUser: 'ErwanDouaille' project: 'SourceCity'; configuration; load. ConfigurationOfSourceCity loadBleedingEdge would it make sense to make a jenkins job for this? -- Best regards, Douaille Erwan douaille.er...@gmail.com -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com Live like you mean it.
Re: [Pharo-dev] Sunburst visualization
This looks like really a fantastic job. I cannot wait to see the code :) Doru On Jul 4, 2013, at 3:20 PM, Alexandre Bergel alexandre.ber...@me.com wrote: Hi! We are currently working on a Sunburst based on top of Roassal. Milton is doing a fantastic job! Here some early screenshots: image copy 2.pngimage copy.pngimage.png Milton Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com If you can't say why something is relevant, it probably isn't.
