- Pharo-users - lists.pharo.org

Re: [Pharo-users] difficult to kill objects - pesky hanging pointersTo

by stepharo

And wht I learned is that we should do ClassOfObjectsThatMustDie allInstances first become: nil but really String new. Le 6/9/16 Ã 02:22, Ben Coman a Ã©crit : > Ohhh... nice... shiny... > > That is much easier to remember. Thanks Andres. > > cheers -ben > > On Tue, Sep 6, 2016 at 5:21 AM, Andres Valloud > <avalloud(a)smalltalk.comcastbiz.net> wrote: >> So why doesn't two-way become: help, e.g. >> >> ClassOfObjectsThatMustDie allInstances first become: String new >> >> As soon as that do-it unwinds there won't be any references to what the new >> string became (the new string wasn't referenced further), so... >> >> >> On 9/5/16 8:50 , Ben Coman wrote: >>> Sometimes its *really* hard to kill some objects. It seems that >>> inspecting a list of pointersTo creates additional hanging references. >>> This was frustrating me just now, so I finally hacked a way forward. >>> Sharing it in case its useful to others, and also I can find it again >>> searching the list. This needs to run for each object. >>> >>> Smalltalk garbageCollect. >>> target := ClassOfObjectsThatMustDie allInstances first. >>> SystemNavigation default allObjectsDo: [ :e | >>> (e isKindOf: Association) ifTrue: [ e value = target ifTrue: [ e >>> value: nil ] ]. >>> (e isKindOf: Array) ifTrue: [ 1 to: e size do: [ :i | (e at: i) = >>> target ifTrue: [ e at: i put: nil ] ] ] >>> ]. >>> target := nil. >>> Smalltalk garbageCollect. >>> >>> cheers -ben >>> >>> >

Sept. 7, 2016

Re: [Pharo-users] [ANN] Territorial

by stepharo

About my tone may I ask a question? Yes sometimes I feel irritated. I'm human and I feel irritated. May be you know the trick that some smart manager use to control the length of meetings... I experienced in our team in the past meetings with 18 people and one guy was always talking a lot more than others. And I was always asking myself: does it have conscience that each minute he is taking is in fact 18 min because we could all spend 1 min doing something else. After that I heard about team that have strange clock where the clock is multiplying by the amount of participants. So when I participate to meetings I always think about what is the value that I bring to other time. Now we are all busy, you see some people in our team and outside told me that they do not have the time to follow Pharo mailing-lists because there are too many emails. And we all lose because the insights of such people could be really great. So some alternatives: - do not care do not read the pharo mailing-list, I would not feel happy with such solution. - be forced to react when something wrong is said because this is important for everybody. And yes sometimes I'm irritated because I feel forced to say something.I have the impression that not saying anything is a kind of luxury that I do not have. - have a closed contributors only mailing-list (not good does not feel nice). This license point is key and this is why I reacted. And I reacted that way because I CARE about our system and I CARE about our communitee. Out there, there is Java, Lua, Python, Ruby, Swift, Objective-C and many more. So we should pay attention to our ecosystem and the license is an integral part of it. So sorry to be rude but I'm ***REALLY*** busy. Much more than you can imagine. Even more. And I feel responsible. Stef Le 7/9/16 Ã 14:40, Dimitris Chloupis a Ã©crit : > Ironically enough "this is our way , take it or leave it" would not > work for Pharo because its smalltalk and basically smalltalk by > architecture allow you to deeply modify the system from the get go. > > This make Pharo technically impossible to control from a dictator and > committee point of view like lets say Python or Linux. CPython is a > single implementation , but with pharo every pharo app is essentially > a new pharo implementation. The moment you modify or extend the pharo > image you make a new pharo implementation. > > I don't like the tone Stef is expressing , he is quite rude and > definitely does not represent the tone of the community which far more > open to dialogue but he is correct , GPL would never have worked for > Pharo. Actually I dont think I have seen a language that is fairly > popular under a GPL license. > > There is of course software under GPL which is sucessful commercially, > Blender is an example, but GPL does not cover 3d assets, music and > sound. In that case you use another kind of license like creative > commons or heavily modify GPL to extend beyond code. So it was > definitely not GPL that made Blender popular, actually it caused a > problem with game developers because games using the BGE (Blender Game > Engine) were at first considered data because the code was packaged > inside the blend file which had a binary format so that meant it was > not covered by GPL because it considered the whole game code just data > (there is a separate executable for loading the game code) but then > Blender decided to change this also to GPL with extending its license > and that pretty much killed commercial games made with Blender. > > So technically you could get away with GPLing Pharo because you could > argue that Pharo image is merely data that the VM loads and not real > source code, which is kinda correct but it would be messy and the > legal interpretation very confusing and uncertain ( leaves a lot of > room for legal interpretation ) . As a company you cannot risk this , > especially while you expect to make big profit. > > As stef said GPL is like a virus, it spread anywhere it touches. Even > if all you do is add a tiny bit of GPL code inside the Pharo image > would turn the entire Pharo implementation including the VM into GPL > and because Pharo tries to approach as many companies as possible as > most other languages do , because money helps improve the popularity > and the quality of the code, MIT is definitely the way to do. > > So its more a "have to" than a "must to". > > Also double license or not its kinda pointless, the moment something > becomes MIT you can be rest assured that people will pick MIT over > GPL. This because you can turn MIT to GPL but you cannot turn GPL to > MIT. So even if you want your project GPLed , MIT is still more than > enough and of course most people will pick MIT for commercial apps so > they don't need to open source their code. > > So no, it does not matter that Spec is double licensed , or if it is > legal that is double licensed , since its active implementation is MIT > this all you need to know. > > So for Pharo and pretty much almost all other programming languages > out there who aspire to be used by as many people as possible and play > an active role in the software market MIT like license is a mandatory > choice. The irony of people not wanting to open source their code but > wanting to use open source code. Its this type of thinking that > justifies the existence of GPL. > > > On Wed, Sep 7, 2016 at 2:59 PM Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > > Hi, > > > On 07/09/16 13:39, stepharo wrote: > > > >> We should not have "The Pharo Way" (TM) or "No way!"... suddenly > >> Markus talk about feedback loops comes to mind, particularly the > >> slide on page 53, regarding "An open source smalltalk ignoring all > >> community contributions"[2]. This is far for being the case in this > >> community and we can keep that scenario at safe distance, if we > show > >> options. So, dual license is an option, git is an option, > markdown is > >> an option. Pharo as a place with options is one where Pharo can > >> fulfill its vision for more people. Let's make these options > visible > >> and figure out the way the work better for a wider community. > > It is amazing how you like talking. > > > > Yes. I like. Is the way to know unwritten history. Not all the > people in > the community know the details as you do, so talking is the way of > going > out of misconceptions, like mine about dual license or state > positions, > like why I don't use Pillar. The "it has been discussed, this is our > way, take or leave it" doesn't help in understanding way. So yes, I'm > all about encouraging dialog/talk if it helps to understand. > > Bye, > > Offray >

Sept. 7, 2016

Re: [Pharo-users] [ANN] Territorial

by stepharo

Yes Peter. I may sound rude but I spent hours, mails.... in the past for example just to have a booth in a conference to promote squeak and this just because of licensing problems. So everybody can do whatever it wants but there is a cost and effect associated with it. Now the argument of oh yes this is good we can have choice is a non-argument and it is not profitable in the long term. Stef Le 7/9/16 Ã 14:08, PBKResearch a Ã©crit : > Stef > > We should not have "The Pharo Way" (TM) or "No way!"... suddenly > > Markus talk about feedback loops comes to mind, particularly the slide > > on page 53, regarding "An open source smalltalk ignoring all community > > contributions"[2]. This is far for being the case in this community > > and we can keep that scenario at safe distance, if we show options. > > So, dual license is an option, git is an option, markdown is an > > option. Pharo as a place with options is one where Pharo can fulfill > > its vision for more people. Let's make these options visible and > > figure out the way the work better for a wider community. > It is amazing how you like talking. > > We can argue and disagree, but let's do it politely. This is just downright rude, and quite unnecessary. > > Peter Kenny > > > > >

Sept. 7, 2016

Re: [Pharo-users] [ANN] Territorial

by stepharo

+1 but as everything we do, it has some impact :) > Hi, > > Please let me stress this: you can put the license of your choice to your code. Is your right and we ensured it continues being your right by choosing MIT license for Pharo. > That means that all frameworks, apps, etc. that runs on Pharo has to be MIT? No! YOU CAN DECIDE. > > But then, if it is not MIT, your code will not be considered for inclusion, just that (but many times you do not have that in mind, so who cares). > In my own case, if is not MIT (or some permissive license like BSD, Apache, etc.) I will not even look inside itâ¦ why? because I do not want to be âinfectedâ: I do not want to have the risk of copying (even innocently) some copyrighted ideas. You do not know the mess that was rewrite entire parts of Pharo to be able to release itâ¦ > So, in the case of contributions to Pharo, yesâ¦ is âour wayâ (which is not a personal statement, is how this community choose to work). > > Anywayâ¦ of course you can always put the license you want to your code (and that applies to Territorial too). > > cheers, > Esteban > > ps: and please forgive Stef for being harsh on thisâ¦ the Spec affaire was painful for us, we do not like to put lawyers and that kind of thing in playâ¦ > >> On 07 Sep 2016, at 14:08, stepharo <stepharo(a)free.fr> wrote: >> >> >> >> Le 7/9/16 Ã 13:58, Offray Vladimir Luna CÃ¡rdenas a Ã©crit : >>> Hi, >>> >>> >>> On 07/09/16 13:39, stepharo wrote: >>>>> We should not have "The Pharo Way" (TM) or "No way!"... suddenly Markus talk about feedback loops comes to mind, particularly the slide on page 53, regarding "An open source smalltalk ignoring all community contributions"[2]. This is far for being the case in this community and we can keep that scenario at safe distance, if we show options. So, dual license is an option, git is an option, markdown is an option. Pharo as a place with options is one where Pharo can fulfill its vision for more people. Let's make these options visible and figure out the way the work better for a wider community. >>>> It is amazing how you like talking. >>>> >>> Yes. I like. Is the way to know unwritten history. Not all the people in the community know the details as you do, so talking is the way of going out of misconceptions, like mine about dual license or state positions, like why I don't use Pillar. The "it has been discussed, this is our way, take or leave it" doesn't help in understanding way. So yes, I'm all about encouraging dialog/talk if it helps to understand. >> this is why I added the comment on the pharo contribution page. >> >>> Bye, >>> >>> Offray >>> >>> >> > >

Sept. 7, 2016

Re: [Pharo-users] UFFI documentation state

by Dimitris Chloupis

Yeap I agree, I have taken a look into documentation in the past when we discussed how similar is UFFI to Nativeboost, my only concern is whether things are about to change and what I learn becomes invalidated after a while which can be quite annoying . When I was playing with Nativeboost and NBOpenGL Igor was so patient and nice with my 1 million questions :D Community support is 50% why I stick with Pharo and considering making professional games with it together with Unreal. Nothing beats the help of a real person ;) On Wed, Sep 7, 2016 at 6:45 PM Ben Coman <btc(a)openinworld.com> wrote: > On Wed, Sep 7, 2016 at 9:12 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > Hi Kilon, > > > > documentation is âongoingâ, but I think the only way I will actually > finish > > it is by answering questions from people (Iâve been pasting there the > > answers I give also in the list). So I would ask you to take a look into > the > > doc and make all the questions that you wantâ¦ so I answer, and I will be > > closer to finish :) > > > > > https://github.com/SquareBracketAssociates/PharoInProgress/blob/master/Unif… > > That doc is certainly off to a good start. Its what I was using ... > enough to get me far enough along to start asking questions :P > cheers -ben > > > > > cheers, > > Esteban > > > > On 07 Sep 2016, at 15:01, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > Hey Esteban hows the documentation for UFFI going ? I will most likely go > > down the Memory Mapped File (Shared Memory) for uniting Pharo with Unreal > > instead of making a Pharo to C++ compiler since it will be much simpler > for > > me but I will need the FFI. Is it stable enough both FFI and its > > documentation or should I wait more ? > > > > > >

Sept. 7, 2016

Re: [Pharo-users] Spur problem?

by ClÃ©ment Bera

Hi, I've never seen that error before. That looks interesting. You need to provide more information. For example the backtrace or something written in PharoDebug.log. Else, as suggested, set a breakpoint in malloc_error_break and try to figure out what is going on. On Wed, Sep 7, 2016 at 4:56 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > Hi, > > While working on a Pharo 5 image for 3-4 hours, I got an image crash and I > was no more able to start the image from the UI interface. When starting > the image from the command line I got the following error: > > Pharo(50871,0xa02c91a8) malloc: *** error for object 0x1af7a04: incorrect > checksum for freed object - object was probably modified after being freed. > > *** set a breakpoint in malloc_error_break to debug > > fish: '/Users/ubhatti/temp/vm-spur/Phaâ¦' terminated by signal SIGBUS > (Misaligned address error). > > The image is about 973 Mb (Moose + seaside + a model for a big industrial > software). This message might not go beyond reporting an error that I do > not know how to produce neither can I share the image (it contains client > proprietary software model and hence we are restricted). > > Just to let you know that there was a problem and n ask if someone has > encountered it before? > > > regards. > > Usman >

Sept. 7, 2016

Re: [Pharo-users] [Pharo-dev] Planning: Pharo Sprints Lille for the rest 2016

by Dimitris Chloupis

I feel experienced enough to join you this time, hope you do slack channel communication because I wont be able to physical attend but I will be available online. I am mostly interested in working on GUI things. On Wed, Sep 7, 2016 at 6:01 PM Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 07 Sep 2016, at 13:05, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > Hi > > > > Here locally we try to organise one âSprintâ per month were we meet to > work on > > boring issue tracker entries together. (external visitors are welcome!) > > > > In the past people organised local sprints at other places at the sane > time (e.g. Santiago/Chile). > > > > The next dates are: > > > > 30 September > > 28 October > This has been moved to 4th November due to holidays > > > 25 November > > 16 December. Pharo Christmas Party! > > > > > > Marcus > > > > >

Sept. 7, 2016

Re: [Pharo-users] UFFI documentation state

by Ben Coman

On Wed, Sep 7, 2016 at 9:12 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Kilon, > > documentation is âongoingâ, but I think the only way I will actually finish > it is by answering questions from people (Iâve been pasting there the > answers I give also in the list). So I would ask you to take a look into the > doc and make all the questions that you wantâ¦ so I answer, and I will be > closer to finish :) > > https://github.com/SquareBracketAssociates/PharoInProgress/blob/master/Unif… That doc is certainly off to a good start. Its what I was using ... enough to get me far enough along to start asking questions :P cheers -ben > > cheers, > Esteban > > On 07 Sep 2016, at 15:01, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Hey Esteban hows the documentation for UFFI going ? I will most likely go > down the Memory Mapped File (Shared Memory) for uniting Pharo with Unreal > instead of making a Pharo to C++ compiler since it will be much simpler for > me but I will need the FFI. Is it stable enough both FFI and its > documentation or should I wait more ? > >

Sept. 7, 2016

Re: [Pharo-users] UFFI cleanup of externally allocated memory (was Re: UFFI const, unsigned, opaque-ish types)

by Ben Coman

On Wed, Sep 7, 2016 at 10:42 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Wed, Sep 7, 2016 at 9:09 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> On 07 Sep 2016, at 14:56, Ben Coman <btc(a)openInWorld.com> wrote: >> >> On Tue, Sep 6, 2016 at 8:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> Hi, >> >> sorry for arriving so late to this, but I was on holidays :) >> this is how autoRelease works: >> >> 1) #autoRelease of an object registers object for finalisation with a >> particular executor. Then behaviour is divided: >> >> 2.1.1) for ExternalAddresses, it just registers in regular way, who will >> call #finalize on GC >> 2.1.2) finalize will just call a free assuming ExternalAddress was allocated >> (which is a malloc) >> >> 2.2.1) for all FFIExternalReference, it will register for finalisation what >> #resourceData answers (normally, the handle of the object) >> 2.2.2) finalisation process will call the object >> class>>#finalizeResourceData: method, with the #resourceData result as >> parameter >> 2.2.3) each kind of external reference can decide how to free that data (by >> default is also just freeing). >> >> An example of this is how CairoFontFace works (or AthensCairoSurface). >> >> >> >> At the bottom of FFIExternalResourceExecutor class comment I read... >> "Note that in #finalizeResourceData: you cannot >> access any other properties of your instance, >> since it is already garbage collected." >> >> But in my experiments it seems okay to access instance variables in >> #finalize. >> For example... >> >> CXString >> autoRelease >> self class finalizationRegistry add: self >> >> CXString >> finalize >> Transcript crShow: 'Finalizing CXString ' ; show: self private_flags. >> self dispose. >> Transcript show: ', done!'. >> >> CXString >>private_flags >> "This method was automatically generated" >> ^handle unsignedLongAt: 5 >> >> Libclang getClangVersion autoRelease. >> Smalltalk garbageCollect. >> "==> Finalizing CXString 1, done! " >> >> >> Is this an unlucky coincidence? Or maybe something changed from NB >> to UFFI? (There is a reference to NB there) >> >> >> yes, is a coincidence. >> the idea of using #finalizeResourceData: is that you keep minimal >> information (in general, just the handle)â¦ this way we ensure instances will >> be collected because we will not have circular references (preventing the >> weakregistry to work). >> >> In general, you can always implement as you did it, but I would prefer the >> #finalizeResourceData: approach, even for structures. >> The only reason it is not implemented is because I didnât reach the >> necessity, then I just skipped it (not in purpose, it was not in my head >> :P), but now is a good moment to implement itâ¦ if you want it :) > > Thanks for the offer, but hold off for the moment. I think I actually > need more than just finalization session management. To get a real > displayable string requires calling the clang_getCString() library > function. I imagine I'd like to call this from CXString>>printOn: -- > but this of course this would break after restarting the image. > > extern "C" { > const char *clang_getCString(CXString string) { > .... > return static_cast<const char *>(string.data); > }} > > typedef struct { > const void *data; > unsigned private_flags; > } CXString; > > So I think I need to register CXString with SessionManager to set *data <-- 0 > on startup. > > An alternative might be adding a session variable to CXString, > FFIExternalStructure subclass: #CXString > instanceVariableNames: 'session' > classVariableNames: '' > poolDictionaries: 'CXStringFlag' > package: 'Libclang' > > except doing so crashes when calling.... > getClangVersion > ^ self ffiCall: #( CXString clang_getClangVersion () ) module: Libclang So this worked... CXString >> resetData handle unsignedLongAt: 1 put: 0. CXString class >> startUp: resuming resuming ifTrue: [ self allInstances do: [ :cxs | cxs resetData ] ]. CXString class >> initialize "self initialize" SessionManager default registerSystemClassNamed: self name Now immediate after a save/restart, doing... CXString allInstances first getString "==> UndefinedObject(nil)" instead of crashing the VM. Can you see/guess any traps hidden from me? Now I wonder early it is practical to prioritise such a reset. My first thought is at least before #printString starts getting called ?? cheers -ben

Sept. 7, 2016

Re: [Pharo-users] Spec: InputWidget question

by Johan Fabry

Hi Brad, the magic of the OK and Cancel buttons is due to the opening of the UI with openDialogWithSpec (instead of openWithSpec). There is info on that in the Spec documentation, in the âManaging Windowsâ chapter (which I finished last week :-) ). You can find a pdf of that chapter here: https://ci.inria.fr/pharo-contribution/view/Books/job/BuildingUIWithSpec/la… HTH -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On Sep 6, 2016, at 18:14, Brad Selfridge <bsselfridge(a)gmail.com> wrote: > > I've been trying for several days to get the Spec InputWidget to work as > expected. I've been running the "example2" example. If you enter text in > the input field and press the "enter" key, then the input text is returned. > But, if you click the "Ok" button rather than "enter" key, then the input > text field is empty. I've tried to dig into why, but I stymied. > > Can someone please help me with this? > > > > ----- > Brad Selfridge > -- > View this message in context: http://forum.world.st/Spec-InputWidget-question-tp4914439.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Sept. 7, 2016