- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

by ClÃ©ment Bera

Hi again, I checked with Stef this morning. Starting the image on a VM without Freetype solves the problem. Just open the VM, remove or rename the Freetype dynamic libraries (FT2, Freetype, 3 libs in total), then start your image. That's unfortunate the hexadecimal editor solution is so much more fun :-) Cheers On Sat, Oct 21, 2017 at 9:30 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Thanks thomas we should find the problem. > > Stef > > On Fri, Oct 20, 2017 at 3:57 PM, Thomas Dupriez > <thomas.dupriez(a)ens-paris-saclay.fr> wrote: > > Hello, > > > > I've had a few issues with Pharo 7 lately. After downloading pharo 7 > images, > > doing some work in them and saving them, the images either instantly > crashe > > or freeze when I try to re-run them. > > If that helps, I was working with and on the calypso browser. > > > > Attached are the crash dump files from some of these faulty images. > > > > vm version: 201708271955 > > image version: 6521 > > OS: Ubuntu 16.04 LTS > > > > Cheers, > > Thomas > > > > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Oct. 24, 2017

Iceberg. Uncommited changes just after loading code from a repo?

by Thomas Dupriez

Hello, After cloning a repo with Iceberg, loading the code and before doing any change, iceberg sees a lot of additions to the code in the "Synchronize Repository" window. Here are the steps I followed: - Load fresh Pharo7 image - Delete the previous clone of my repo in /home/dupriez/Pharo/vms/70-x86/pharo-local/iceberg (to start afresh) - Open Iceberg: Â Â Â - Click on "Clone Repository", to clone git@github.com:dupriezt/Calypso.git Â Â Â - Right-click on the repo in the list, Metacello/install baseline of Calypso (default) Â Â Â - Switch to dev branch, creating a local dev branch in the process as prompted Â Â Â - Without making any change, if I right-click on the Calypso repo in the list and click 'Synchronize Repository', there is a significant list of additions ready to be commited. Can someone shed some light on this? How can I get the code of the dev branch of this repo as is in my image? Cheers, Thomas Dupriez

Oct. 24, 2017

Re: [Pharo-dev] Bloc Feedback

by Tudor Girba

Hi, Indeed, instance variables is what we are mainly concerned with as well. We keep on trimming, but it still feels like too many variables. Cheers, Doru > On Oct 24, 2017, at 8:59 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2017-10-24 2:04 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Tudor Girba-2 wrote > > Thanks for the feedback! > > But of course! Thanks for pushing Bloc :) IMHO a clean low-level graphics > framework is the linchpin to unleash a tremendous amount of creativity in > the Pharo community. I have several dream projects that I placed on > long-term hold after getting stuck in Morphic quicksand :/ > > > Tudor Girba-2 wrote > >> - How would one do e.g. a ticking clock in Bloc? The only possibly > >> relevant > >> example I see is BlAnimatedCursor. Is that a typical usage? One thing > >> that > >> I'm not sure how to translate to a BlElement is that the cursor seems to > >> be > >> responsible for starting and stopping the animation via #activateOn:, > >> which > >> doesn't exist for an element. How would one prevent an element's > >> animation > >> from continuing to run after a space was closed? > > What do you mean? > > I guess I mean what is the Bloc version of #step that would enable us to do > e.g. Squeak's mouse-eyes-tracking-the-cursor or Lively Kernel's clock: > <http://forum.world.st/file/t128965/Chromium5.png> > > > Tudor Girba-2 wrote > >> - BlElement has 278 instance-side methods. A frequent battle cry against > >> Morphic was the bloated Morph class with 899. Definitely an improvement, > >> but > >> are we "there yetâ? > > What do you mean? > > Is there a consensus on a maximum number of instance-side methods before a > class becomes impossible to understand, and if so where does BlElement fall > on that scale? > > > > > I dont think this number alone is a problem. As long as the "responsibility" of this > class is well structured. > A problem with the Morph class is, that it acts as many things at once. > A structured container, a model, a view, a graphical object, a widget base ... > > About BlElement, I am more afraid about the number of instance variables > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html -- www.tudorgirba.com www.feenk.com "Sometimes the best solution is not the best solution."

Oct. 24, 2017

Re: [Pharo-dev] Bloc Feedback

by Nicolai Hess

2017-10-24 2:04 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Tudor Girba-2 wrote > > Thanks for the feedback! > > But of course! Thanks for pushing Bloc :) IMHO a clean low-level graphics > framework is the linchpin to unleash a tremendous amount of creativity in > the Pharo community. I have several dream projects that I placed on > long-term hold after getting stuck in Morphic quicksand :/ > > > Tudor Girba-2 wrote > >> - How would one do e.g. a ticking clock in Bloc? The only possibly > >> relevant > >> example I see is BlAnimatedCursor. Is that a typical usage? One thing > >> that > >> I'm not sure how to translate to a BlElement is that the cursor seems to > >> be > >> responsible for starting and stopping the animation via #activateOn:, > >> which > >> doesn't exist for an element. How would one prevent an element's > >> animation > >> from continuing to run after a space was closed? > > What do you mean? > > I guess I mean what is the Bloc version of #step that would enable us to do > e.g. Squeak's mouse-eyes-tracking-the-cursor or Lively Kernel's clock: > <http://forum.world.st/file/t128965/Chromium5.png> > > > Tudor Girba-2 wrote > >> - BlElement has 278 instance-side methods. A frequent battle cry against > >> Morphic was the bloated Morph class with 899. Definitely an improvement, > >> but > >> are we "there yetâ? > > What do you mean? > > Is there a consensus on a maximum number of instance-side methods before a > class becomes impossible to understand, and if so where does BlElement fall > on that scale? > > > I dont think this number alone is a problem. As long as the "responsibility" of this class is well structured. A problem with the Morph class is, that it acts as many things at once. A structured container, a model, a view, a graphical object, a widget base ... About BlElement, I am more afraid about the number of instance variables > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Oct. 24, 2017

Re: [Pharo-dev] [Seaside] [ANN] SeasideTesting recovered from oblivion

by Norbert Hartl

Cool. Need to think where it is useful. On the one hand testing without external components is good. On the other hand you can only test very simple stuff with it. But there might be a place. Btw. you donât need selenium with parasol. You can use chrome-standalone which implements the same protocol. Norbert > Am 23.10.2017 um 12:04 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > Hi, > > I spend some days last week woking with the guys of AFI (http://afi-sa.fr, yes they also use Pharo in some of their projects) and together we recovered SeasideTesting from Davis Shaffer to be used for their TDD experience. > > you can check it out here: https://github.com/Afibre/SeasideTesting > > Whatâs SeasideTesting? A package to test Seaside components. > Why we do not use Parasol? Because it is based on selenium and that makes the process slow. > Where can I know more? > - there is some documentation here (for VW, I think): http://www.shaffer-consulting.com/david/Seaside/TestingComponents/TestingCo… > - some slides here (on squeak): http://esug.org/data/ESUG2005/Wednesday/2005-ESUG-Shaffer.pdf > but all that is old. Best way is to just install and see the tests, as always, > > > cheers! > Esteban > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Oct. 24, 2017

Re: [Pharo-dev] Bloc status

by Tudor Girba

> On Oct 24, 2017, at 2:09 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tudor Girba-2 wrote >> right now we have three such "real life scenariosâ that you can play with: > > Are these safe to load in a working image? IOW could one switch back and > forth between the standard and experimental toolset? > I work with them loaded when in a production image. Cheers, Doru > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- www.tudorgirba.com www.feenk.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

Oct. 24, 2017

Re: [Pharo-dev] Bloc status

by Tudor Girba

Thanks. That menu is experimental, and will be removed. In the meantime, the file is in: ./pharo-local/iceberg/feenkcom/gtoolkit-visualizer/doc/mondrian/index.pillar Cheers, Doru > On Oct 24, 2017, at 3:57 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tudor Girba-2 wrote >> You can find more details here: >> https://github.com/feenkcom/gtoolkit > > Installed per instructions there. [World Menu]->[Moldable Editor]->[3. > Pillar Documenter]->[Do It and Go] -> [Click "Pillar" > tab]->"FileDoesNotExist: File @ ~/Dynabook/Working Images/GT > Preview/pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar" > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- www.tudorgirba.com www.feenk.com "Beauty is where we see it."

Oct. 24, 2017

Re: [Pharo-dev] Bloc status

by Sean P. DeNigris

Tudor Girba-2 wrote > You can find more details here: > https://github.com/feenkcom/gtoolkit Installed per instructions there. [World Menu]->[Moldable Editor]->[3. Pillar Documenter]->[Do It and Go] -> [Click "Pillar" tab]->"FileDoesNotExist: File @ ~/Dynabook/Working Images/GT Preview/pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar" ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 24, 2017

Re: [Pharo-dev] UnifiedFFI Docs

by Todd Blanchard

https://pharo.fogbugz.com/f/cases/20574/FFITypeArray-annonymousClassCreator… <https://pharo.fogbugz.com/f/cases/20574/FFITypeArray-annonymousClassCreator…> There you go. > On Oct 22, 2017, at 2:42 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > >> On 21 Oct 2017, at 21:15, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Esteban will probably reply to this thread > > yes, I will :) > >> >> >> On Thu, Oct 19, 2017 at 10:34 PM, Todd Blanchard <tblanchard(a)mac.com> wrote: >>> I have found the problem with VoidPointer3 generating accessors. > > can you report that on fogbugz ? > (along with your solution) > > thanks! > Esteban > >>> >>> No idea how to contribute back a fix but this is what I've found. >>> >>> FFITypeArrayType>>annonymousClassCreator >>> ^ String streamContents: [ :stream | >>> stream >>> nextPutAll: '(FFITypeArray ofType: '; >>> print: (self objectClass type isPointer ifTrue: [self externalTypeWithArity >>> printString] ifFalse: ['#',self objectClass type class]); >>> nextPutAll: ' size: '; >>> print: self objectClass numberOfElements; >>> nextPutAll: ')' ] >>> >>> Recalling that we are trying to come up with an accessor that can pull out a >>> void*[3], this produces >>> >>> '(FFITypeArray ofType: #FFIVoid size: 3)' >>> >>> which produces an error as FFIVoid's size is undefined. In general, this >>> will be wrong for any pointer type and will probably get the size >>> calculation wrong. >>> >>> Doing a little digging I find that >>> >>> FFITypeArray>>ofType: aType size: aSize >>> >>> delegates resolution of aType to FFIExternalType>>resolveType:aType and this >>> can take all kinds of different things including the native type name. >>> >>> It would be better if this generated the native name for pointers. >>> >>> (FFITypeArray ofType: 'void*' size: 3) >>> >>> So I changed it to: >>> >>> FFITypeArrayType>>annonymousClassCreator >>> ^ String streamContents: [ :stream | >>> stream >>> nextPutAll: '(FFITypeArray ofType: '; >>> print: (self objectClass type isPointer >>> ifTrue: [self externalTypeWithArity printString] >>> ifFalse: ['#',self objectClass type class]); >>> nextPutAll: ' size: '; >>> print: self objectClass numberOfElements; >>> nextPutAll: ')' ] >>> >>> and this seems to work fine. >>> >>> Onwards... >>> >>> On Oct 19, 2017, at 7:18 AM, Todd Blanchard <tblanchard(a)mac.com> wrote: >>> >>> Thatâs great - itâs been kind of magical but a couple things have changed >>> since you wrote it and some bugs have crept into ffi. >>> >>> Right now Iâm finding the generated accessor for the VoidPointer3 is >>> actually generating a void 3 accessor and that doesnât work. I spent all day >>> yesterday tracking it to the accessor generating code. >>> >>> Sent from the road >>> >>> On Oct 18, 2017, at 22:29, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> >>> >>> On Thu, Oct 19, 2017 at 1:05 AM, Todd Blanchard <tblanchard(a)mac.com> wrote: >>>> >>>> I'm working through Ben's great blog post about playing with libclang and >>>> I am puzzled by something. >>> >>> >>> Thx Todd. Knowing someone is looking at it encourages me to expand it. >>> I'm interested in looking at your specific questions, but it might not be >>> until next week after this stint of long work days. >>> >>> cheers -ben >>> >>> >>>> >>>> >>>> invalidateSessionData >>>> handle atAllPut: 0. >>>> >>>> zero;s out the handle. Cool. However, >>>> >>>> handle isNull >>>> >>>> does not return true despite it being used in the getString method as >>>> >>>> ^ handle isNull >>>> ifTrue: ['external memory invalidated by session restart'] >>>> ifFalse:[LibClang clang_getCString__cxString: self]. >>>> >>>> Looks like there should be an isNull on ByteArray that returns true if all >>>> bytes are zero but it isn't there. Was it dropped for some reason? >>>> >>>> >>>> >>>> On Oct 18, 2017, at 2:58 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> >>>> wrote: >>>> >>>> Sure the documentation could be better, that is definetly important, but >>>> is already good enough and UFFI is a very technical subject much more suited >>>> to a mailing list . Its not physical possible to cover the massive potential >>>> of UFFI. >>>> >>>> On Wed, Oct 18, 2017 at 9:32 AM Stephane Ducasse <stepharo.self(a)gmail.com> >>>> wrote: >>>>> >>>>> Please do not hesitate to do Pull Requests. >>>>> Luc told me that he wants to do a pass on it and Esteban promises that to >>>>> me >>>>> but he is super busy. >>>>> >>>>> Stef >>>>> >>>>> >>>>> On Wed, Oct 18, 2017 at 5:54 AM, Todd Blanchard <tblanchard(a)mac.com> >>>>> wrote: >>>>>> Wonderful! Thanks. >>>>>> >>>>>>> On Oct 17, 2017, at 3:45 PM, stephan <stephan(a)stack.nl> wrote: >>>>>>> >>>>>>> On 17-10-17 23:06, Todd Blanchard wrote: >>>>>>>> Anyone know what happened to this? >>>>>>>> >>>>>>>> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… >>>>>>> >>>>>>> https://github.com/SquareBracketAssociates/Booklet-uFFI >>>>>>> >>>>>>> has a link to a bintray pdf download >>>>>>> >>>>>>> Stephan >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> > >

Oct. 24, 2017

Re: [Pharo-dev] Bloc status

by Sean P. DeNigris

Tudor Girba-2 wrote > right now we have three such "real life scenariosâ that you can play with: Are these safe to load in a working image? IOW could one switch back and forth between the standard and experimental toolset? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 24, 2017