[Pharo-project] Success story: NTed
I must not forget to write what we do from time to time. We (@2denker in cooperation with a local university) built a monitoring tool for disaster scenario recovery rehearsals. Several times a year universities, red cross, THW und hospitals are planning a rehearsal together. For this an environment is prepared for a simulated disaster (car accidents, explosions in civil areas, …). The local environment is prepared to look real as well as film make-up artist prepare people for injuries (broken legs, open head, …). The rehearsal should improve the coordination of several hospitals, firemen…as well as the quickest possible treatment for the injured. One important part of the rehearsal is monitoring of what happens. This is achieved by installing a local position system and using our tool. Every injured person gets a wireless tablet. On the tablet there are UI elements that indicate treatment done to them. Whenever a doctor comes visiting the injured person activates the corresponding UI button. The events are transmitted to a server and are prepared for another analysis software. The tablet enables the HQ to make contact to individual persons or groups. The tablet measures times of needed treatments and instructs the injured to be dead if measurements weren't taken in time. Technically it is done in smalltalk solo. The server is a pharo image. It has - web admin interface with complex forms for managing injuries, injured, groups, etc. For this we used seaside because it is best suited for this job. Forms are done with magritte, magritte-bootstrap. The interface also displays the live incoming events and other data - a static file server that delivers static resources to client tablets - a websocket connector that is used by the clients to connect to the server - a http handler to export data to other analysis tools The client is done with amber smalltalk. It - loads the web page containing amber from the server - connects back to the server - downloads a UI spec for the injured using the tablet to display personalized UI elements - stores events on the tablet in case the injured is offline - measures times to instruct the injured If you have any questions please don't hesitate to ask. Norbert
Re: [Pharo-project] [Pharo-users] [ANN] RFB for pharo 2.0
I've added you. Norbert Am 07.05.2013 um 12:20 schrieb Henrik Johansen : > > On May 7, 2013, at 10:56 AM, Norbert Hartl wrote: > >> I moved the sources for RFB from Lukas' site to smalltalkhub >> >> http://smalltalkhub.com/#!/~PharoExtras/RFB/ >> >> I also copied the ConfigurationOfRFB from MetacelloRepository to >> smalltalkhub. There I applied the changes for RFB to be runnable in pharo >> 2.0. >> >> To load it use >> >> Gofer it >> smalltalkhubUser: 'PharoExtras' project: 'RFB'; >> configuration; >> load. >> >> (Smalltalk at: #ConfigurationOfRFB) load >> >> Norbert > Would you mind applying the fix from > http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/60796 ? > About time there was a version of RPB not leaking semaphores, but I don't > have commit rights to the new home either :P > > Cheers, > Henry
[Pharo-project] [ANN] RFB for pharo 2.0
I moved the sources for RFB from Lukas' site to smalltalkhub http://smalltalkhub.com/#!/~PharoExtras/RFB/ I also copied the ConfigurationOfRFB from MetacelloRepository to smalltalkhub. There I applied the changes for RFB to be runnable in pharo 2.0. To load it use Gofer it smalltalkhubUser: 'PharoExtras' project: 'RFB'; configuration; load. (Smalltalk at: #ConfigurationOfRFB) load Norbert
Re: [Pharo-project] RFB in 2.0
thanks. Damien added me 20 minutes ago ;) Norbert Am 06.05.2013 um 19:17 schrieb Igor Stasenko : > just checked, you're already listed on: > http://www.smalltalkhub.com/#!/~PharoExtras > > On 6 May 2013 18:23, Norbert Hartl wrote: >> thanks, >> >> I knew the next question upfront but was reluctant to ask in the last mail >> for access to PharoExtras. >> >> Would someone add me please? >> >> Norbert >> >> >> Am 06.05.2013 um 18:20 schrieb stephane ducasse : >> >> this is called PharoExtras. >> >> Stef >> >> On May 6, 2013, at 6:16 PM, Norbert Hartl wrote: >> >> >> Am 03.05.2013 um 20:09 schrieb Mariano Martinez Peck >> : >> >> >> >> >> On Fri, May 3, 2013 at 3:05 PM, Norbert Hartl wrote: >>> >>> >>> Am 03.05.2013 um 20:00 schrieb Mariano Martinez Peck >>> : >>> >>> Hi Norbert, >>> >>> I would move it to its own new repo in SmalltalkHub. >>> >>> Ok, but then it goes under my private section, right? >> >> >> you can put it under PharoContributions team. >> >> >> How can I do that? I don't find anything like PharoContributions on >> smalltalkhub. >> >> Norbert >> >>> >>> Also, I had another problem with RFB and the UIManager. The solution I >>> found was this one: http://samadhiweb.com/blog/2012.11.04.headless.rfb.html >>> I don't like it because I need to change Pharo's base source, but I didn't >>> spend time finding a better solution...I guess there is, though. >>> >>> The first line of code all my images (deployed on server using RFB) see is >>> >>> UIManager default: MorphicUIManager new. >>> >> >> I was going to do that as well. But it is not clear to me WHERE you write >> that line of code. Because even if you save the image with that, doesn't the >> image set its own UI manager when booting? So I guess you need to pass >> around a script when running the image or something? >> What about adding RFB at startup list and implement #startUp doing >> "UIManager default: MorphicUIManager new." ? >> >> Best, >> >> >>> >>> With that I don't have problems at all. >>> >>> thanks, >>> >>> Norbert >>> >>> Best, >>> >>> >>> >>> >>> On Fri, May 3, 2013 at 2:56 PM, Norbert Hartl wrote: >>>> >>>> I've found the problem. There is a FileDirectory access in >>>> RFBSession>>#desktopName. Removing it makes RFB work. >>>> >>>> The current RFB sources are on Lukas' server. What do we do with that >>>> stuff? Move to smalltalkhub? If not I can ask Lukas to give me write >>>> permission. Just wanted to ask what kind of behaviour is en vogue this >>>> days. >>>> >>>> Norbert >>>> >>>> Am 03.05.2013 um 19:31 schrieb Norbert Hartl : >>>> >>>>> Esteban, >>>>> >>>>> now I can tell that it isn't working for me either. Socket is open and >>>>> server is running. But there are immediate disconnects when trying to >>>>> connect to a pharo2.0 image. >>>>> >>>>> Did you figure it out? >>>>> >>>>> Norbert >>>> >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> > > > > -- > Best regards, > Igor Stasenko. >
Re: [Pharo-project] RFB in 2.0
thanks, I knew the next question upfront but was reluctant to ask in the last mail for access to PharoExtras. Would someone add me please? Norbert Am 06.05.2013 um 18:20 schrieb stephane ducasse : > this is called PharoExtras. > > Stef > > On May 6, 2013, at 6:16 PM, Norbert Hartl wrote: > >> >> Am 03.05.2013 um 20:09 schrieb Mariano Martinez Peck : >> >>> >>> >>> >>> On Fri, May 3, 2013 at 3:05 PM, Norbert Hartl wrote: >>> >>> Am 03.05.2013 um 20:00 schrieb Mariano Martinez Peck >>> : >>> >>>> Hi Norbert, >>>> >>>> I would move it to its own new repo in SmalltalkHub. >>>> >>> Ok, but then it goes under my private section, right? >>> >>> you can put it under PharoContributions team. >>> >> How can I do that? I don't find anything like PharoContributions on >> smalltalkhub. >> >> Norbert >> >>> >>>> Also, I had another problem with RFB and the UIManager. The solution I >>>> found was this one: http://samadhiweb.com/blog/2012.11.04.headless.rfb.html >>>> I don't like it because I need to change Pharo's base source, but I didn't >>>> spend time finding a better solution...I guess there is, though. >>>> >>> The first line of code all my images (deployed on server using RFB) see is >>> >>> UIManager default: MorphicUIManager new. >>> >>> >>> I was going to do that as well. But it is not clear to me WHERE you write >>> that line of code. Because even if you save the image with that, doesn't >>> the image set its own UI manager when booting? So I guess you need to pass >>> around a script when running the image or something? >>> What about adding RFB at startup list and implement #startUp doing >>> "UIManager default: MorphicUIManager new." ? >>> >>> Best, >>> >>> >>> With that I don't have problems at all. >>> >>> thanks, >>> >>> Norbert >>> >>>> Best, >>>> >>>> >>>> >>>> >>>> On Fri, May 3, 2013 at 2:56 PM, Norbert Hartl wrote: >>>> I've found the problem. There is a FileDirectory access in >>>> RFBSession>>#desktopName. Removing it makes RFB work. >>>> >>>> The current RFB sources are on Lukas' server. What do we do with that >>>> stuff? Move to smalltalkhub? If not I can ask Lukas to give me write >>>> permission. Just wanted to ask what kind of behaviour is en vogue this >>>> days. >>>> >>>> Norbert >>>> >>>> Am 03.05.2013 um 19:31 schrieb Norbert Hartl : >>>> >>>> > Esteban, >>>> > >>>> > now I can tell that it isn't working for me either. Socket is open and >>>> > server is running. But there are immediate disconnects when trying to >>>> > connect to a pharo2.0 image. >>>> > >>>> > Did you figure it out? >>>> > >>>> > Norbert >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >> >
Re: [Pharo-project] RFB in 2.0
Am 03.05.2013 um 20:09 schrieb Mariano Martinez Peck : > > > > On Fri, May 3, 2013 at 3:05 PM, Norbert Hartl wrote: > > Am 03.05.2013 um 20:00 schrieb Mariano Martinez Peck : > >> Hi Norbert, >> >> I would move it to its own new repo in SmalltalkHub. >> > Ok, but then it goes under my private section, right? > > you can put it under PharoContributions team. > How can I do that? I don't find anything like PharoContributions on smalltalkhub. Norbert > >> Also, I had another problem with RFB and the UIManager. The solution I found >> was this one: http://samadhiweb.com/blog/2012.11.04.headless.rfb.html >> I don't like it because I need to change Pharo's base source, but I didn't >> spend time finding a better solution...I guess there is, though. >> > The first line of code all my images (deployed on server using RFB) see is > > UIManager default: MorphicUIManager new. > > > I was going to do that as well. But it is not clear to me WHERE you write > that line of code. Because even if you save the image with that, doesn't the > image set its own UI manager when booting? So I guess you need to pass > around a script when running the image or something? > What about adding RFB at startup list and implement #startUp doing > "UIManager default: MorphicUIManager new." ? > > Best, > > > With that I don't have problems at all. > > thanks, > > Norbert > >> Best, >> >> >> >> >> On Fri, May 3, 2013 at 2:56 PM, Norbert Hartl wrote: >> I've found the problem. There is a FileDirectory access in >> RFBSession>>#desktopName. Removing it makes RFB work. >> >> The current RFB sources are on Lukas' server. What do we do with that stuff? >> Move to smalltalkhub? If not I can ask Lukas to give me write permission. >> Just wanted to ask what kind of behaviour is en vogue this days. >> >> Norbert >> >> Am 03.05.2013 um 19:31 schrieb Norbert Hartl : >> >> > Esteban, >> > >> > now I can tell that it isn't working for me either. Socket is open and >> > server is running. But there are immediate disconnects when trying to >> > connect to a pharo2.0 image. >> > >> > Did you figure it out? >> > >> > Norbert >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com
Re: [Pharo-project] about logCr: vs. log: vs. trace:/traceCr:
Am 06.05.2013 um 08:00 schrieb Denis Kudriashov : > Hello. > > What about logging levels? > > I like "logInfo:", "logDebug:", "logTrace:". Or maybe it is better to split > log with levels: "self log info:", "self log debug:", "self log trace:" > I think that opens a can of worms. What Stef wants is a "say something" method that is easy to use and commonly useful. Adding logging levels is a specialized form of logging that is not commonly useful, it's just commonly used in less reflective environments. So my proposal would be to have an equivalent to "self log" where you can return your own logging facility on which you can do "self log info: 'something'". I changed my kind of logging some time ago. I just log objects. A log object isn't much more than to put it on top of a collection. While I'm not using strings for logging I have objects where I can attach all my use case dependent stuff. You could even put something like a log level information in those objects. I log Errors as well as progress state objects,etc. It is easy to process the whole log collection (now or afterwards) because all necessary state is still there. Another reason why I don't like strings for that is that I put the log messages as json in elasticsearch/mongo because I want to query them to find errornous behaviour. Well, sometimes I do both: Store it in a database and write it to disk. Because I don't convert it to a string at first possible time I can do that easily. We don't put sources in files so we shouldn't put log information only there. Make logging information a first class citizen! Norbert > Best regards, > Denis > > 2013/5/5 Stéphane Ducasse > Hi guys > > Stupidly I introduced log: a while ago to replace Transcript show:. Now is > the current situation. > > I still want to remove all the use of Transcript show: > > Now since I thought I did a mistake with log: because it overload > Integer>>log: I introduced trace: and traceCr: > > Now I do not like traceCr: because it is not a cool message. > > So what do we do: > > 1) we use crLog:, logCr: > and deprecated log: > > > 2) we use crTrace:, trace: and traceCr: > > I really prefer solution 1 but I would like to hear from you. > > Stef >
Re: [Pharo-project] about logCr: vs. log: vs. trace:/traceCr:
Am 05.05.2013 um 21:42 schrieb Stéphane Ducasse : > Hi guys > > Stupidly I introduced log: a while ago to replace Transcript show:. Now is > the current situation. > > I still want to remove all the use of Transcript show: > > Now since I thought I did a mistake with log: because it overload > Integer>>log: I introduced trace: and traceCr: > > Now I do not like traceCr: because it is not a cool message. > > So what do we do: > > 1) we use crLog:, logCr: > and deprecated log: > > > 2) we use crTrace:, trace: and traceCr: > > I really prefer solution 1 but I would like to hear from you. I assume crLog:/logCr: is a short and convenient form of something else. How would these be called? Basically I want to log objects and only the default in Object should use Transcript in combination with "asString". On top of the short form a convenient selector that adds a line ending makes sense. There needs to be a getter for a log where one can attach all needs like logging levels, log destinations, etc. So is the plan to have only the direct replacement for "Transcript show:" or something that can be extended/used differently. And why do we use cr? I think it is pretty common to us NL = newline. Where does this come from? Logically a "carriage return" enables you only to print something in bold while newline enables you to print a whole page :) Norbert
Re: [Pharo-project] Zeroconf and OS string
Am 05.05.2013 um 10:44 schrieb "p...@highoctane.be" : > on Mobaxterm the output of uname -a is > > [Philippe.DELLGFX] → uname -a > CYGWIN_NT-6.1-WOW64 DELLGFX 1.7.17(0.262/5/3) 2012-10-28 12:24 i686 GNU/Linux > > > Clearly no Windows in there. > Hmm, I think you are running Windows 7 on a Dell laptop :) CYGWIN_NT-6.1 should be windows enough in there, right? CYG is a good information and the rest you can look up at http://en.wikipedia.org/wiki/Windows_NT_6.1 Norbert
Re: [Pharo-project] How to "fix" "broken" mcz files?
Am 05.05.2013 um 10:07 schrieb Holger Hans Peter Freyther :
> Hi,
>
> when I port a project to GNU Smalltalk I tend to use the snapshot/*.st
> and convert it. Now with some MCZ versions of Aida/Iliad this is failing
> because the fileout is broken. The fileout is broken in a way that at
> some point (without a BOM) the creator started to use UCS-4 (or such) for
> the strings.
>
> This can be seen here[1] and either manually extracting the source and
> using FileStream>>#fileIn: or by using the MczInstaller on the mcz file
> (which is not working on the snapshot of the MCDefinition) the import
> will fail.
>
> Is this a known/fixed problem with Monticello/Pharo? Is there a way to
> re-create the source.st from the snapshot of the MCDefinitions?
>
Yes, the problem is known. Monticello has no handling for encoding. The last
time I looked into it I could see that Monticello is assuming a latin1
encoding. As soon as you include a non-latin1 character in the source it will
be turned into a WideString. When this is written to disk either our
UCS-4+leadingChar format is written or even worse in way that every byte of a
WideString is latin1 encoded then. I'm not sure in any way it isn't the right
way to do it.
I started to fix this a couple of years ago but as most of the time the problem
is deeply embedded in the image and grows the longer you look at it. And that
exceeds my time frame I have for these things massively.
The problem is easier to fix for the .st file because in case of String
representations ('') or the usage of the String class it is platform
independent. In the binary blob the platform specific classes like WideString
appear that make it unreadable on other platforms. Here the canonical way of
encoding something in utf-8 would also mean that platform dependent class are
treated in the same canonical way to use only String instead of platform
dependent ones. A platform that reads a monticello file gets utf-8 decodes it
and then on occurrence of a wide character would then turn it into a platform
dependent class, etc.
So, in order to "fix" this I think the only feasible way is to get rid of
non-latin1 characters in the source and save the package again. This is how it
is done, e.g. in seaside. If someone really needs some non latin1 characters
they should be included programmatically, meaning at the right position in code
use "Character value: …"
Norbert
Re: [Pharo-project] [ANN] A SmalltalkHub server for each
Am 04.05.2013 um 13:38 schrieb Sven Van Caekenberghe : > > On 04 May 2013, at 13:33, Norbert Hartl wrote: > >> Huh? Didn't think a second about it not being completely obvious that I was >> making a joke. >> >> I think I'm quite familiar with what is possible and what is not because I >> spent nearly _your_ complete lifetime on those things :) > > Norbert, you are (becoming) a grumpy old man with a beard ;-) Nope, because the beard has gone 2 months ago ;) > >> Norbert >> >> Am 04.05.2013 um 12:51 schrieb Benjamin >> : >> >>> You really think you can break thing from the Amber browser on client side ? >>> >>> Ben >>> >>> On May 4, 2013, at 10:33 AM, Norbert Hartl wrote: >>> >>>> >>>> >>>> Am 04.05.2013 um 07:29 schrieb Ben Coman : >>>> >>>>> Igor Stasenko wrote: >>>>>> On 4 May 2013 01:01, Javier Pimás wrote: >>>>>> >>>>>>> Cool! And I just discovered that typing smalltalk.Browser._open() in the >>>>>>> javascript console on smalltalkhub site lets you see how the client side >>>>>>> works. >>>>>> >>>>>> Just don't break it please. I need st-hub in working state :) >>>>> What are the security implications of this ? >>>>> I guess no more than plain Javascript - the server should not blindly >>>>> trust what the client sends. >>>>> >>>> See! That's a good example why "security by obscurity" does not work. It >>>> just needs a hacker like Javier to workaround it easily. So Javier has >>>> control over all of the servers? That's not goo...wait a minute..maybe it >>>> is good to have another administrator of the site..? Hmmm... >>>> >>>> Norbert >>> > >
Re: [Pharo-project] [ANN] A SmalltalkHub server for each
Huh? Didn't think a second about it not being completely obvious that I was making a joke. I think I'm quite familiar with what is possible and what is not because I spent nearly _your_ complete lifetime on those things :) Norbert Am 04.05.2013 um 12:51 schrieb Benjamin : > You really think you can break thing from the Amber browser on client side ? > > Ben > > On May 4, 2013, at 10:33 AM, Norbert Hartl wrote: > >> >> >> Am 04.05.2013 um 07:29 schrieb Ben Coman : >> >>> Igor Stasenko wrote: >>>> On 4 May 2013 01:01, Javier Pimás wrote: >>>> >>>>> Cool! And I just discovered that typing smalltalk.Browser._open() in the >>>>> javascript console on smalltalkhub site lets you see how the client side >>>>> works. >>>> >>>> Just don't break it please. I need st-hub in working state :) >>> What are the security implications of this ? >>> I guess no more than plain Javascript - the server should not blindly trust >>> what the client sends. >>> >> See! That's a good example why "security by obscurity" does not work. It >> just needs a hacker like Javier to workaround it easily. So Javier has >> control over all of the servers? That's not goo...wait a minute..maybe it is >> good to have another administrator of the site..? Hmmm... >> >> Norbert >
Re: [Pharo-project] [ANN] A SmalltalkHub server for each
Am 04.05.2013 um 07:29 schrieb Ben Coman : > Igor Stasenko wrote: >> On 4 May 2013 01:01, Javier Pimás wrote: >> >>> Cool! And I just discovered that typing smalltalk.Browser._open() in the >>> javascript console on smalltalkhub site lets you see how the client side >>> works. >> >> Just don't break it please. I need st-hub in working state :) > What are the security implications of this ? > I guess no more than plain Javascript - the server should not blindly trust > what the client sends. > See! That's a good example why "security by obscurity" does not work. It just needs a hacker like Javier to workaround it easily. So Javier has control over all of the servers? That's not goo...wait a minute..maybe it is good to have another administrator of the site..? Hmmm... Norbert
Re: [Pharo-project] RFB in 2.0
In case of RFB I want it mostly with morphic ui manager. On the other hand it is an option when starting my server. The images runs headless anyway because there is no display driver. I don't see a problem here. Norbert Am 03.05.2013 um 20:17 schrieb "Sean P. DeNigris" : > Mariano Martinez Peck wrote >> What about adding RFB at startup list and implement #startUp doing >> "UIManager default: MorphicUIManager new." ? > > But you don't necessarily always want it to be headful, do you? If you have > a headless server image, then use RFB to debug, then it seems you would want > to subsequently start headless again, and then maybe realize you need to > debug more and start Morphic... Could there be a concept of an RFB session, > so when a connection is made to the RFB socket, the session is started > (including installing the correct UI Manager), and then cleared manually or > on shutdown (reinstalling the original manager)... how does that sound? > > > > - > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/RFB-in-2-0-tp4685418p4685430.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >
Re: [Pharo-project] RFB in 2.0
Am 03.05.2013 um 20:00 schrieb Mariano Martinez Peck : > Hi Norbert, > > I would move it to its own new repo in SmalltalkHub. > Ok, but then it goes under my private section, right? > Also, I had another problem with RFB and the UIManager. The solution I found > was this one: http://samadhiweb.com/blog/2012.11.04.headless.rfb.html > I don't like it because I need to change Pharo's base source, but I didn't > spend time finding a better solution...I guess there is, though. > The first line of code all my images (deployed on server using RFB) see is UIManager default: MorphicUIManager new. With that I don't have problems at all. thanks, Norbert > Best, > > > > > On Fri, May 3, 2013 at 2:56 PM, Norbert Hartl wrote: > I've found the problem. There is a FileDirectory access in > RFBSession>>#desktopName. Removing it makes RFB work. > > The current RFB sources are on Lukas' server. What do we do with that stuff? > Move to smalltalkhub? If not I can ask Lukas to give me write permission. > Just wanted to ask what kind of behaviour is en vogue this days. > > Norbert > > Am 03.05.2013 um 19:31 schrieb Norbert Hartl : > > > Esteban, > > > > now I can tell that it isn't working for me either. Socket is open and > > server is running. But there are immediate disconnects when trying to > > connect to a pharo2.0 image. > > > > Did you figure it out? > > > > Norbert > > > > > > -- > Mariano > http://marianopeck.wordpress.com
Re: [Pharo-project] RFB in 2.0
I've found the problem. There is a FileDirectory access in RFBSession>>#desktopName. Removing it makes RFB work. The current RFB sources are on Lukas' server. What do we do with that stuff? Move to smalltalkhub? If not I can ask Lukas to give me write permission. Just wanted to ask what kind of behaviour is en vogue this days. Norbert Am 03.05.2013 um 19:31 schrieb Norbert Hartl : > Esteban, > > now I can tell that it isn't working for me either. Socket is open and server > is running. But there are immediate disconnects when trying to connect to a > pharo2.0 image. > > Did you figure it out? > > Norbert
[Pharo-project] RFB in 2.0
Esteban, now I can tell that it isn't working for me either. Socket is open and server is running. But there are immediate disconnects when trying to connect to a pharo2.0 image. Did you figure it out? Norbert
Re: [Pharo-project] How i can retrieve the global by its name?
Am 02.05.2013 um 06:03 schrieb Igor Stasenko : > #SomeName asGlobal > > (or suggest more appropriate/precise method name for a symbol) I think if you write asGlobalWhat? the problems with this becomes visible. As Steph wrote there is asClass which does it for the case you are looking for a class. I'm not sure how common the use case Smalltalk at: #foo put: somethingThatIsNotAClass is. Your selector is somewhat orthogonal to asClass as you define access via reachability and not via type. But trying to imagine the future asGlobal is not a good selector. At least I hope the "global" will go away completely. In that case it wouldn't be good to rely on. Another possibility that would make sense is asBinding (or a better name) but that would only be good if it would search scopes upwards. So it can look into e.g. block -> method -> class -> environment -> ? And that would defeat the purpose of your mail in another way. So what is your rationale? My gut says I like the idea but I can't think of a useful selector/concept to make it a viable option. Norbert
Re: [Pharo-project] save as...
Am 30.04.2013 um 15:35 schrieb Camillo Bruni : > > On 2013-04-30, at 15:24, Norbert Hartl wrote: > >> Was there a discussion about "save as…" should not increment the image file >> number? Any links to it or was it by accident. >> >> In my opinion I liked the difference between save = same file name, save as… >> = new automatical filename > > I think so too, and that's the current behavior no? > No, when you try "save as…" you get the current image name and clicking on ok tells the file already exists and if you like to overwrite it. Norbert
[Pharo-project] save as...
Was there a discussion about "save as…" should not increment the image file number? Any links to it or was it by accident. In my opinion I liked the difference between save = same file name, save as… = new automatical filename Norbert
Re: [Pharo-project] Smart Suggestion Version 1
Am 24.04.2013 um 10:42 schrieb Marcus Denker : > > On Apr 24, 2013, at 10:30 AM, Norbert Hartl wrote: > >> >> Am 24.04.2013 um 10:00 schrieb Goubier Thierry : >> >>>> Maybe we can make a destination between two cases: >>>> >>>> 1) cursor is placed somewhere. Here people are interested in >>>> suggestions. The context menu like it is now makes sense >>>> (I would add one entry for the suggestions, in addition to the >>>> shortcut) >>>> >>>> 2) The user *selected* something explicitly. Here I think we should show >>>> a modified context menu that only has those things >>>> the make sense on the selection. Nobody want to "Debug it" a >>>> variable, or "print it" a syntactically invalid selection... >>> >>> Hum, this one looks cool. The default action menu is quite long (debugIt, >>> exploreIt, etc...) and making it shorter is a nice touch. >> >> Yes, but unfortunately it doesn't work that way most of the time for the >> unexperienced.. Learning a UI means knowing where things are. A changing >> context menu mostly leads to confusion because you struggle finding things >> you saw before. Those things only make sense if you're already comfortable >> with the UI and the environment. I think that is one reason we menu entries >> are often just greyed out. This way you have the orientation because the >> menu is of the same shape and by seeing greyed out stuff you can immediately >> learn that some menu entries do not make sense in this context. >> Maybe the way it can work is to have this as an option. First grey out >> things and the expert can switch them off to make disabled entries invisible. >> > But aren't *context* menus named like that because they depend on the context? It doesn't help much if you use a term consistently if the thing _the term describes_ doesn't work out at the end. And according to wikipedia they were called pop-up menus in smalltalk :) > If I get a context menu for a class or a method in the panes above, they are > different, too. I didn't mean that there is only one menu in the system and it has to look the same everywhere. I just wanted to note that there are things to take care of when building menu logic. Norbert
Re: [Pharo-project] Smart Suggestion Version 1
Am 24.04.2013 um 10:00 schrieb Goubier Thierry : >> Maybe we can make a destination between two cases: >> >> 1) cursor is placed somewhere. Here people are interested in >> suggestions. The context menu like it is now makes sense >> (I would add one entry for the suggestions, in addition to the >> shortcut) >> >> 2) The user *selected* something explicitly. Here I think we should show >> a modified context menu that only has those things >> the make sense on the selection. Nobody want to "Debug it" a >> variable, or "print it" a syntactically invalid selection... > > Hum, this one looks cool. The default action menu is quite long (debugIt, > exploreIt, etc...) and making it shorter is a nice touch. Yes, but unfortunately it doesn't work that way most of the time for the unexperienced.. Learning a UI means knowing where things are. A changing context menu mostly leads to confusion because you struggle finding things you saw before. Those things only make sense if you're already comfortable with the UI and the environment. I think that is one reason we menu entries are often just greyed out. This way you have the orientation because the menu is of the same shape and by seeing greyed out stuff you can immediately learn that some menu entries do not make sense in this context. Maybe the way it can work is to have this as an option. First grey out things and the expert can switch them off to make disabled entries invisible. But then I'm far from being an UI/UX expert. Norbert
Re: [Pharo-project] Argument names created by Debugger
Am 18.04.2013 um 23:13 schrieb Igor Stasenko : > On 18 April 2013 23:02, Norbert Hartl wrote: >> >> >> Am 18.04.2013 um 22:15 schrieb "Sean P. DeNigris" : >> >>> I tweaked the code because in my most common case, I don't care that it's >>> e.g. aByteString, but only that it's aString: >>> >>> (argument isKindOf: String) ifTrue: [ ^ 'aString' ]. >>> (argument isKindOf: Collection) ifTrue: [ ^ 'aCollection' ]. >>> (argument isKindOf: Integer) ifTrue: [ ^ 'anInteger' ]. >>> >>> Am I the only one, or would this be useful for everyone? lmk and I'll >>> prepare a slice... >>> >> Sure, strikes me all the time! What keeps you from delegating this to the >> argument object itself. It doesn't need to be the name selector. >> > Indeed... To the hell these case statements. It should be one-liner: > > ^ argument class canonicalArgumentName > Yes. Or ^ argument class mostCommonDialectIndependentSuperClass name Well, I suck at names but you get the idea :) And demeter shall forgive me this time. Norbert
Re: [Pharo-project] Argument names created by Debugger
Am 18.04.2013 um 22:15 schrieb "Sean P. DeNigris" : > I tweaked the code because in my most common case, I don't care that it's > e.g. aByteString, but only that it's aString: > >(argument isKindOf: String) ifTrue: [ ^ 'aString' ]. >(argument isKindOf: Collection) ifTrue: [ ^ 'aCollection' ]. >(argument isKindOf: Integer) ifTrue: [ ^ 'anInteger' ]. > > Am I the only one, or would this be useful for everyone? lmk and I'll > prepare a slice... > Sure, strikes me all the time! What keeps you from delegating this to the argument object itself. It doesn't need to be the name selector. Norbert
Re: [Pharo-project] Pharo 2.0 and Zinc - big thanks!
Am 17.04.2013 um 03:09 schrieb Igor Stasenko : > > i wonder why people so obsessed with web? > it is ugly, and dead before born.. > > Why ugly? The dead beforn born part remembers me of a programming language we all love. Why resurrect? :) Hmm, maybe because there is potential. Uhh, the same goes for the web. So, stay tuned! Norbert > On 17 April 2013 02:19, Ben Coman wrote: >> Torsten Bergmann wrote: >>> >>> Thanks - Pharo 2.0 and Zinc makes it really easy >>> to work with, write AND test HTTP stuff: >>> >>> >> >> That sparks an idea, perhaps for a student project... >> That a general HTTP testing framework for use against non-Pharo systems >> could be just the thing to help the uptake of Pharo in "enterprises". The >> level of trust required for an internal testing tool is less than that >> required for an end-user system. This might be a good stepping stone for >> enterprises which may initially view Smalltalk a bit strange. >> Unless of course best practice is to use web testing tools from within real >> web browsers (I not familiar with what the options are). Perhaps a website >> stress test tool where the live exceptions can be inspected is something >> that other tools cannot do. >> >> cheers -ben >> > > > > -- > Best regards, > Igor Stasenko. >
Re: [Pharo-project] Understanding Athens
If you go for ppa you have two options. Compile everything when building the package or just packaging binaries. So have to set either Build-Depends: libcairo2-dev or/and Depends: libcairo2 in the debian/control file. The architecture you build your stuff for is i386. With the modern multi-arch support you can install e.g. a i386 version in an amd64 environment. Much better than to force a 64bit shell for a 32bit executable. Norbert Am 16.04.2013 um 13:40 schrieb Igor Stasenko : > P.S. i also asked Damien to look for the ways how we can tell system > that installation depends on cairo-32 bit package (for ppa distro). > > On 16 April 2013 13:35, Igor Stasenko wrote: >> On 16 April 2013 13:23, kilon wrote: >>> Doru , I am using Pharo 2.0 from the main website , also it does not matter >>> because cairo libraries are looked outside the pharo folder. >>> >>> If you open system browser and go to the CairoLibraryLoader>>getLibraryPath >>> (class side) you will see it tries to find cairo libs in >>> '/usr/lib/libcairo.so' . On the other hand there are cairo libs included for >>> the windows version inside the pharo folder. Its kinda wierd that they are >>> not included for macos and linux. >>> >> For mac and windows we bundle VM together with cairo library. >> For linux, since they have a standardized way of installing third-party libs, >> you're on your own. >> >> Yes, it would be nice if we can get a precise instructions how to >> install 32-bit libs >> so other people can use them. >> >>> Pavel , you mid sharing how you installed 32 bit cairo, because I googled it >>> and I could not find anything on the subject. Thanks. >>> >>> Oh and if anyone can answer my stackoverflow questions i will be more than >>> grateful. I am prepared to contribute to >>> Athens as much as I can and even port mophic to it BUT i need first to >>> understrand what is going on. >> >> Sure, I will check and try to answer them. >> >>> I have read >>> Cairo documentation and now all i need is to decypher athens so be prepared >>> for a bombarment of questions. >>> >> You're welcome. >> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Understanding-Athens-tp4681820p4681847.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko. >
Re: [Pharo-project] RFB server and 2.0
Am 15.04.2013 um 20:43 schrieb Esteban Lorenzano : > damn :( > > I have a connection refused (in pharo it looks like running, but...) > What does netstat -atn | grep 5900 say? Norbert > Esteban > > On Apr 15, 2013, at 8:39 PM, Mariano Martinez Peck > wrote: > >> It worked for me when I tried 2 or 3 weeks ago >> >> >> On Mon, Apr 15, 2013 at 3:37 PM, Esteban Lorenzano >> wrote: >> Hi, >> >> Someone has tried RFB in 2.0? I installed it, but looks like it is not >> working :( >> >> Esteban >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >
Re: [Pharo-project] Versionner in 2.0 again
Hi Christophe, looks pretty good to me. I did only quick tests. If I find anything I get back to you. Thanks for your effort. That was one missing piece for me to switch more projects to pharo 2.0 Norbert Am 15.04.2013 um 16:30 schrieb Christophe Demarey : > Hi Norbert, > > I just add a look at your changes. > In my opinion, all stuff related to ConfigurationBaseName shouldn't be > changed. The root of the problem is the Metacello ToolBox version. > I added a new configuration for Versionner (in ss3) for Pharo2. I tested it a > bit and it looks fine. > > What you need : > 1/ Load (don't merge) Metacello-ToolBox-dkh.130 from > http://seaside.gemstone.com/ss/metacello in your Pharo2 image. > 2/ Load ConfigurationOfVersionner from http://ss3.gemstone.com/ss/Versionner > 3/ ConfigurationOfVersionner load > > Let me know if it solves your issues. > > Regards, > Christophe. > > > Le 11 avr. 2013 à 17:40, Christophe Demarey a écrit : > >> Hi Norbert, >> >> Sorry, I don't read Pharo ML every day else I will never have time to work >> on Versionner... I only have a part time to do that. >> What I'm doing on Versionner is to add the possibility to update your >> configurations at a very fine grained (add/remove projects/packages/groups). >> This version is a WIP and not yet usable. I'm not so far to have one version >> open for beta-test but I now face issues with Metacello on Pharo2 and some >> missing API in the toolbox. >> >> That's why I'm now working to have Metacello tests green on Pharo2. >> What I'm doing: >> update builderCi (used by Dale to test Metacello on Travis) to support >> Pharo2/3 : almost done >> be able to load MetacelloPreview on Pharo2/3 >> have green tests. >> >> With a clean and up to date metacello environment for Pharo, I will be able >> to focus on Versionner and have a result soon. >> >> I also did not take time to port the "old" Versionner on Pharo2 since I will >> face the same issues with Metacello/Pharo2. >> The problem is not really Versionner itself but the fact that it relies on >> libraries not tested and not fully working on Pharo2. >> >> I will take a look at your work. (some comments below). >> >> Thanks for your contribution. >> >> Regards, >> Christophe. >> >> >> Le 11 avr. 2013 à 13:18, Norbert Hartl a écrit : >> >>> Huh, I find it strange that nobody cares. Does anybody use Versionner? >>> >>> Norbert >>> >>> >>> Am 09.04.2013 um 11:31 schrieb Norbert Hartl : >>> >>>> Yesterday I tried again to use Versionner in 2.0 but did have much >>>> success. So I tried myself (because I think Versionner is important) and >>>> could final generate a new version of my project using versionner. >>>> >>>> Following things I noticed (I'm writing this because I'm not sure which >>>> issue to open for what package. I'm just want opinions and after that I >>>> can open/upload whatever): >>>> >>>> I loaded Versionner from Metacello (taken from [1]) >>>> >>>> Gofer new >>>> url: 'http://ss3.gemstone.com/ss/Versionner'; >>>> package: 'ConfigurationOfVersionner'; >>>> load. >>>> (Smalltalk at: #ConfigurationOfVersionner) perform: #load >>>> >>>> monticello issues >>>> = >>>> >>>> While updating the rest of the packages to the newest I saw that >>>> >>>> Versionner-Core-Model-ChristopheDemarey.19 >>>> >>>> has an older ancestor for fixing something for pharo 1.4. The package >>>> >>>> Versionner-Core-Model-ChristopheDemarey.20 >>>> >>>> merged the packages back to HEAD but reverted some things like >>>> SystemAnnouncer back to SystemChangeNotifier. >> >> I tried to switch at a time to Pharo2 but too many issues. So I switched >> back to Pharo1.4 to be able to work on Versionner. >> >>>> So I'm using >>>> >>>> Versionner-Core-Model-ChristopheDemarey.18 >>>> and >>>> Versionner-Core-Commands-ChristopheDemarey.17 >>>> >>>> as older packages. Any other package is the newest in the repository. >> >> I will check that you don't have useless parts of the new Versionner. >> As it is difficult to maintain branches with Monticello, I move
Re: [Pharo-project] Stroke of genius
Am 15.04.2013 um 15:46 schrieb Sven Van Caekenberghe : > > On 15 Apr 2013, at 15:07, "Sean P. DeNigris" wrote: > >> Sven Van Caekenberghe-2 wrote >>> the little fact that it is incremental - it updates and saves the same >>> image based on 1 metacello configuration - is really a stroke of genius. >>> It saves an enormous amount of time as in the past I always did a complete >>> build from scratch. Updating servers is now really a joy. >> >> Sounds great! And, I don't exactly understand ;) Can you say more about that >> feature? > > Building a new image goes like this > > $ ./vm.sh Pharo.image save test > > $ ./vm.sh test.image config http://mc.stfx.eu/XXX ConfigurationOfBetaNineT3 > --install=bleedingEdge --username=XXX --password=XXX > > The Pharo.image is 'empty' as far as your own code is concerned, the config > loads lots of dependencies. A build takes 10 minutes or so. > > But the next time, you can do only the second part > > $ ./vm.sh test.image config http://mc.stfx.eu/XXX ConfigurationOfBetaNineT3 > --install=bleedingEdge --username=XXX --password=XXX > > The test.image contains all your project specific code, and loading the > config just checks all dependencies and only loads what has changed, > incrementally. It only takes some 10s of seconds. > > It never occurred to me that this was the way to go, but the config handler > does it by default. Maybe it is just me, but I had the impression that > everybody (including CIs) always built from scratch (more or less, there were > staged systems), while it is actually quite practical to keep on updating the > same image for a much faster turn around. > This is less reliable than building from scratch. If you only build your own packages without a lot of external packages that might go well. If there are external dependencies it can even be that not loading it from scratch will get you a different package set installed in your image afterwards. So you should build from scratch from time to time anyway. For the config handler I don't see a reason why a config option should overwrite the existing image by default. Without extra options I don't even see why the image should shutdown after loading the config. Is it how it is? That looks like there are too many assumptions taken from the commandline handlers. Norbert
Re: [Pharo-project] On cleaning image startup list
Am 14.04.2013 um 21:27 schrieb Igor Stasenko : > pfff... > > DateAndTime class>>initialize > >super initialize. > > NEVER EVER call super initialize for class initializers! > > I think we should add a lint rule for that. > Can you explain why? Norbert
Re: [Pharo-project] DateAndTime bug: we should do something about it
No offense taken. It is not my code. I'm just guilty by resolving a ticket and integrating it. So maybe I should have taken more time looking at it. Norbert Am 13.04.2013 um 00:16 schrieb Igor Stasenko : > On 12 April 2013 23:47, Norbert Hartl wrote: >> >> Am 12.04.2013 um 23:23 schrieb Igor Stasenko : >> >>> On 12 April 2013 23:14, p...@highoctane.be wrote: >>>> +1. No clue either. But discovered the terminate process shortcut to kill >>>> them faster... >>>> >>>> Coping over solving ... >>> >>> One of the "solutions" i proposed is to rewrite the code and get rid >>> of "nano-second" """"synchronization""" of date and time with system clock >>> because >>> a) there is no real users of it (to my knowledge) >>> b) you cannot have precision higher than precision of system primitive >>> we're using, >>> which is in millisecond range.. >> Where do you see a nanosecond synchronization? It is still millisecond clock >> as far as I can see. Only the instVar is called nanos. > > Ah, sorry.. i mistaken by some orders of magnitude. ;) > > The offending code starts from here: > > initializeOffsets >| durationSinceEpoch secondsSinceMidnight nowSecs | >LastTick := 0. >nowSecs := self clock secondsWhenClockTicks. >LastMilliSeconds := self millisecondClockValue. >durationSinceEpoch := Duration >days: SqueakEpoch >hours: 0 >minutes: 0 >seconds: nowSecs. >DaysSinceEpoch := durationSinceEpoch days. >secondsSinceMidnight := (durationSinceEpoch - >(Duration >days: DaysSinceEpoch >hours: 0 >minutes: 0 >seconds: 0)) asSeconds. >MilliSecondOffset := secondsSinceMidnight * 1000 - LastMilliSeconds > > (notice that 1000 multiplier, which gives us "nanosecond" precision) > > But that's fine.. now look at > > secondsWhenClockTicks > >"waits for the moment when a new second begins" > >| lastSecond | > >lastSecond := self primSecondsClock. >[ lastSecond = self primSecondsClock ] whileTrue: [ (Delay > forMilliseconds: 1) wait ]. > >^ lastSecond + 1 > > that is complete nonsense. Sorry. > > This code relying on primSecondsClock resolution, which is. (drum > roll. ) > 1 second.. > > then it is combined with millisecondClockValue , as you see later to get > system time with millisecond precision.. > > I am not genius in math and physics.. but even i understand that if > you measurement has error X > you cannot get more precision than X, even if you combine it with > another measurement with higher precision. > > (But i can be wrong with that.. if so, please explain why) > > >> >>> c) i see it completely stupid to try to do magic tricks trying to be >>> smart and squeeze more >>> precision than underlying system can offer. >>> >>> For that: i would use non-existing-yet primitive, lets say: >>> >>> >>> >>> and since this primitive fails, because it don't exists, the fallback >>> will use old primitive which >>> currently in VM.. >>> >>> because (repeating again) doing black magick and trickery in image >>> buys us nothing and only serves as a source of bugs. >> >> Can you explain where the black magic happens? > > Sure. > See > initializeOffsets > secondsWhenClockTicks > and all of the users of LastMilliSeconds class var.. > > btw, did i mentioned, that if we get rid of that code, DateAndTime > will no longer need startup? > I am just amazed at the shitloads of code which doing this stuff.. and > has nothing to do with correct/precise measurement of system date and > time. > > Sorry if it offends you or anyone else. As i said before, my attacks > is always against bad code, > never against people. I just saying how i feel when i see it. > >> I integrated the cuis changeset back then because I wanted something more >> fine grained than seconds. Do you think this is already black magic? I think >> we can make smaller slices today :) That it forces the whole DateAndTime in >> this precision is probably not necessary and I understand that Sven did his >> own timestamp. The same goes for timezones. Maybe we need more levels of >> features in the hierarchy. If the system (or any software) is not dependent >> on precision below a second it would be good to have such a coarse grained >> type
Re: [Pharo-project] DateAndTime bug: we should do something about it
Am 12.04.2013 um 23:23 schrieb Igor Stasenko : > On 12 April 2013 23:14, p...@highoctane.be wrote: >> +1. No clue either. But discovered the terminate process shortcut to kill >> them faster... >> >> Coping over solving ... >> > > One of the "solutions" i proposed is to rewrite the code and get rid > of "nano-second" synchronization""" of date and time with system clock > because > a) there is no real users of it (to my knowledge) > b) you cannot have precision higher than precision of system primitive > we're using, > which is in millisecond range.. > Where do you see a nanosecond synchronization? It is still millisecond clock as far as I can see. Only the instVar is called nanos. > c) i see it completely stupid to try to do magic tricks trying to be > smart and squeeze more > precision than underlying system can offer. > > For that: i would use non-existing-yet primitive, lets say: > > > > and since this primitive fails, because it don't exists, the fallback > will use old primitive which > currently in VM.. > > because (repeating again) doing black magick and trickery in image > buys us nothing and only serves as a source of bugs. Can you explain where the black magic happens? I integrated the cuis changeset back then because I wanted something more fine grained than seconds. Do you think this is already black magic? I think we can make smaller slices today :) That it forces the whole DateAndTime in this precision is probably not necessary and I understand that Sven did his own timestamp. The same goes for timezones. Maybe we need more levels of features in the hierarchy. If the system (or any software) is not dependent on precision below a second it would be good to have such a coarse grained type at hand. But to have the possibility to have at least milliseconds I find important. My wild guess would be the startup initialization of DateAndTime. It takes quite while to do. So the code forks off the initialization in order not to slow down startup. Without knowing exactly my gut tells me this is not a good idea. It might be that it produces late jumps of time in startup which makes timeouts inactive. Or jumps the check for negative delays and introduces some negative wait which will native wise quit big. Were we at "wild guessing" or "very wild guessing" again? Norbert
Re: [Pharo-project] DateAndTime bug: we should do something about it
funny, I wanted to look at it in my actual 2.0 working image and I don't have a single occurrence of it. It is a 2.0 image? Norbert Am 12.04.2013 um 23:08 schrieb Igor Stasenko : > I tried to find the cause but failed... > > this thing is annoying.. > > lets look at the code and brainstorm, about: > 1) what happening > 2) how we can fix it > > because i am out of ideas.. > and having this crap replicating itself in our images is not tolerable. > > -- > Best regards, > Igor Stasenko. >
Re: [Pharo-project] [3.0] Actions done in 3.0...
Am 12.04.2013 um 10:53 schrieb Marcus Denker : > Hi, > > This time we should just write it down when we do it… > > Actions in Pharo 3.0 > https://pharo.fogbugz.com/default.asp?W64 > So true! Great! Especially for people like me. Norbert
Re: [Pharo-project] [3.0] CI build is broken
Am 11.04.2013 um 14:44 schrieb Camillo Bruni : > Norbert, > I deprecated now the old scripts and I had a look at your script proposal > and I extended it a bit: > > https://gist.github.com/dh83/5363000 > > what do you think? > Looks good to me, although I find … IMAGE="$DIR/Pharo.image"; if [ ! -z "$IMAGE" ]; … is a bit superfluous :) Agreed? Norbert P.S.: Thanks for picking it up. I need to have a look at the zeroconf stuff. > On 2013-04-02, at 12:02, Camillo Bruni wrote: > >> Yes I just haven't fully announced it yet ;) since I only programmed them >> this saturday and was waiting for the pharo conf ;) >> >> But I will deprecate it with a warning message in it tomorrow or so. >> And then people should rename their scripts. >> >> >> On 2013-04-02, at 11:58, Norbert Hartl wrote: >> >>> Well, I would say a >>> >>> mv vm-ui.sh pharo-ui >>> >>> would do a good job to get out of deprecation. Honestly if the scripts are >>> deprecated just take them out of the download. I don't know why to leave >>> them there because it is confusing. >>> >>> Norbert >>> >>> Am 02.04.2013 um 11:24 schrieb Esteban Lorenzano : >>> >>>> Hi Norbert, >>>> >>>> the vm-ui.sh script is deprecated (yep, Camillo already deprecated >>>> something, even if it is brand new). >>>> >>>> now the valid scripts are >>>> >>>> "pharo" and "pharo-ui" >>>> >>>> :) >>>> >>>> Esteban >>>> >>>> On Apr 2, 2013, at 11:17 AM, Norbert Hartl wrote: >>>> >>>>> Another attempt. >>>>> >>>>> Norbert >>>>> >>>>> >>>>> >>>>> Am 02.04.2013 um 10:43 schrieb Norbert Hartl : >>>>> >>>>>> Ah, rats, didn't think it through. It only works for commandline >>>>>> switches that do not have an argument itself. Sad and sorry! >>>>>> >>>>>> Norbert >>>>>> >>>>>> Am 02.04.2013 um 10:38 schrieb Norbert Hartl : >>>>>> >>>>>>> Very good Cami. I have two remarks. If it should be short I think that >>>>>>> >>>>>>> curl -sL get.pharo.org | bash >>>>>>> >>>>>>> is shorter than >>>>>>> >>>>>>> wget --quiet -O - get.pharo.org | bash >>>>>>> >>>>>>> If I see it correct the script is used for CI but as there is a >>>>>>> get.pharo.org host I assume it is supposed to be an easy entry point >>>>>>> for all kind of users, right? >>>>>>> >>>>>>> If this is true I find it somewhat strange to have a >>>>>>> download-all-in-one-and-cozy-script that downloads everything needed >>>>>>> but to start it I have still to provide the image myself to the shell >>>>>>> scripts. So I added this to the script >>>>>>> >>>>>>> # parse vm options and image >>>>>>> for arg in "$@" >>>>>>> do >>>>>>> if [[ $arg == -* ]]; >>>>>>> then >>>>>>> VMOPTIONS="$VMOPTIONS $arg" >>>>>>> shift >>>>>>> else >>>>>>> break >>>>>>> fi >>>>>>> done >>>>>>> IMAGE=$1 >>>>>>> shift >>>>>>> # if no image has been provided use the installed one >>>>>>> if [ -z "$IMAGE" ]; >>>>>>> then >>>>>>> IMAGE=$DIR/Pharo.image >>>>>>> fi >>>>>>> >>>>>>> which uses the downloaded image in case nothing has been specified on >>>>>>> the commandline. >>>>>>> >>>>>>> Hope you like it. Usually I would extract the same portion of both >>>>>>> scripts to an extra file but then there is the trade-off to have one >>>>>>> more file in the download. I'll attach a version of vm-ui.sh for you to >>>>>>> try. If you need help I'm happy to chime in for this. >>>>>>> >>>>>>> thanks for the effort, >>>>>>> >>>>>>> Norbert >>>>>>> >>>>>>> >>>>>>> >>>>>>> Am 02.04.2013 um 09:15 schrieb Camillo Bruni : >>>>>>> >>>>>>>> we're back up, shinier than ever ;) >>>>>>>> >>>>>>>> check http://get.pharo.org ;) >>>>>>>> >>>>>>>> now you can use: >>>>>>>>wget --quiet -O - get.pharo.org | bash >>>>>>>> for the current stable release of Pharo and the PharoVM. >>>>>>>> >>>>>>>> On 2013-04-01, at 22:52, Tudor Girba wrote: >>>>>>>>> No stress. In the worst case you can fix it tomorrow during the >>>>>>>>> tutorial :). >>>>>>>>> >>>>>>>>> Doru >>>>>>>>> >>>>>>>>> >>>>>>>>> On Apr 1, 2013, at 10:26 PM, Camillo Bruni >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2013-04-01, at 22:09, "Sean P. DeNigris" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Tudor Girba-2 wrote >>>>>>>>>>>> Could it have something to do with the latest optimizations of >>>>>>>>>>>> Camillo? >>>>>>>>>>> >>>>>>>>>>> Probably... Cami breaks everything :-P >>>>>>>>>> >>>>>>>>>> dammit, I wanted to silently add the new zeroconf scripts >>>>>>>>>> obviously something went horribly wrong there, sorry guys.. working >>>>>>>>>> on it! >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> www.tudorgirba.com >>>>>>>>> >>>>>>>>> "What is more important: To be happy, or to make happy?" >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> > >
Re: [Pharo-project] Versionner in 2.0 again
Huh, I find it strange that nobody cares. Does anybody use Versionner? Norbert Am 09.04.2013 um 11:31 schrieb Norbert Hartl : > Yesterday I tried again to use Versionner in 2.0 but did have much success. > So I tried myself (because I think Versionner is important) and could final > generate a new version of my project using versionner. > > Following things I noticed (I'm writing this because I'm not sure which issue > to open for what package. I'm just want opinions and after that I can > open/upload whatever): > > I loaded Versionner from Metacello (taken from [1]) > > Gofer new > url: 'http://ss3.gemstone.com/ss/Versionner'; > package: 'ConfigurationOfVersionner'; > load. > (Smalltalk at: #ConfigurationOfVersionner) perform: #load > > monticello issues > = > > While updating the rest of the packages to the newest I saw that > > Versionner-Core-Model-ChristopheDemarey.19 > > has an older ancestor for fixing something for pharo 1.4. The package > > Versionner-Core-Model-ChristopheDemarey.20 > > merged the packages back to HEAD but reverted some things like > SystemAnnouncer back to SystemChangeNotifier. So I'm using > > Versionner-Core-Model-ChristopheDemarey.18 > and > Versionner-Core-Commands-ChristopheDemarey.17 > > as older packages. Any other package is the newest in the repository. > > metacello toolbox issues > == > > I don't know much about metacello toolbox but the separation of files into > ConfigurationOf and Baseline seems to have potential for confusion. There is > a notion of a basename so it can build ConfigurationOfMyProject as well as > BaselineOfMyProject (MyProject being the basename). But in the > MetacelloToolbox in the pharo2.0 repository it does not seem right. I had to > change the code to use (MBToolbox baseNameOf: …) at a few places. I took > orientation from the message signature. If a method expects a > configurationBaseName and the sender used the configuration class I changed > it. I'll attach the mcz for now to this mail until it is clear what to do. > > versionner issues > = > > At one place I added a metacello toolbox name conversion because it made > sense to make it there. The other thing I had to fix is a method notification > that takes the wrong entity from an announcement. Both packages attached as I > don't have commit rights and don't know where the issue tracker for > versionner is if there is any) > > I would be glad if any of you guys that know about that stuff could drop me a > note if this is ok or where I've gone wrong. > > thanks, > > Norbert > > > [1] http://users.dcc.uchile.cl/~jsandova/versionner/ > > > >
Re: [Pharo-project] [ANN] Pharo VM packages and PPA for Ubuntu
Am 08.04.2013 um 13:05 schrieb Damien Cassou : > On Mon, Apr 8, 2013 at 11:35 AM, Goubier Thierry > wrote: >> sudo apt-get download pharo-vm >> sudo dpkg -i --ignore-depends openssl:i386 pharo-* > > > thank you. I wrote that on the PPA web page > I don't even think that it is work-around. It would be a work-around if you don't need any ssl support. Treating it like this you should face complaints of users why Zinc SSL isn't working. I'm not sure if the automatic installation of a broken package is a benefit for anyone. Let's just fix the multiarch build. Norbert > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >
Re: [Pharo-project] [Pharo-users] [ANN] Pharo VM packages and PPA for Ubuntu
That's great! I think providing packages for LTS versions of ubuntu would be good. Norbert Am 07.04.2013 um 21:12 schrieb Damien Cassou : > Dear Pharo and Ubuntu users, > > Nicolas Petton and I are proud to announce Ubuntu packages for the > Pharo VM. Installing the pharo vm is now just a matter of: > > sudo add-apt-repository ppa:cassou/pharo > sudo apt-get update > sudo apt-get install pharo-vm > > With this package, you get: > > - the latest pharo vm as a 'pharo' binary in the PATH > - all plugins and libraries (native boost, freetype, ssl, ...) > - file association so you can just double-click on pharo images > - pharo icons visible everywhere (on image files, on ALT+TAB...) > - PharoV10.sources and PharoV20.sources > > Please fill bug reports on https://pharo.fogbugz.com. > > This package is currently only available for Ubuntu 12.10 Quantal. > Fill a bug report if you want me to package it for another version of > Ubuntu. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >
Re: [Pharo-project] [3.0] CI build is broken
Well, I would say a mv vm-ui.sh pharo-ui would do a good job to get out of deprecation. Honestly if the scripts are deprecated just take them out of the download. I don't know why to leave them there because it is confusing. Norbert Am 02.04.2013 um 11:24 schrieb Esteban Lorenzano : > Hi Norbert, > > the vm-ui.sh script is deprecated (yep, Camillo already deprecated something, > even if it is brand new). > > now the valid scripts are > > "pharo" and "pharo-ui" > > :) > > Esteban > > On Apr 2, 2013, at 11:17 AM, Norbert Hartl wrote: > >> Another attempt. >> >> Norbert >> >> >> >> Am 02.04.2013 um 10:43 schrieb Norbert Hartl : >> >>> Ah, rats, didn't think it through. It only works for commandline switches >>> that do not have an argument itself. Sad and sorry! >>> >>> Norbert >>> >>> Am 02.04.2013 um 10:38 schrieb Norbert Hartl : >>> >>>> Very good Cami. I have two remarks. If it should be short I think that >>>> >>>> curl -sL get.pharo.org | bash >>>> >>>> is shorter than >>>> >>>> wget --quiet -O - get.pharo.org | bash >>>> >>>> If I see it correct the script is used for CI but as there is a >>>> get.pharo.org host I assume it is supposed to be an easy entry point for >>>> all kind of users, right? >>>> >>>> If this is true I find it somewhat strange to have a >>>> download-all-in-one-and-cozy-script that downloads everything needed but >>>> to start it I have still to provide the image myself to the shell scripts. >>>> So I added this to the script >>>> >>>> # parse vm options and image >>>> for arg in "$@" >>>> do >>>> if [[ $arg == -* ]]; >>>> then >>>> VMOPTIONS="$VMOPTIONS $arg" >>>> shift >>>> else >>>> break >>>> fi >>>> done >>>> IMAGE=$1 >>>> shift >>>> # if no image has been provided use the installed one >>>> if [ -z "$IMAGE" ]; >>>> then >>>> IMAGE=$DIR/Pharo.image >>>> fi >>>> >>>> which uses the downloaded image in case nothing has been specified on the >>>> commandline. >>>> >>>> Hope you like it. Usually I would extract the same portion of both scripts >>>> to an extra file but then there is the trade-off to have one more file in >>>> the download. I'll attach a version of vm-ui.sh for you to try. If you >>>> need help I'm happy to chime in for this. >>>> >>>> thanks for the effort, >>>> >>>> Norbert >>>> >>>> >>>> >>>> Am 02.04.2013 um 09:15 schrieb Camillo Bruni : >>>> >>>>> we're back up, shinier than ever ;) >>>>> >>>>> check http://get.pharo.org ;) >>>>> >>>>> now you can use: >>>>> wget --quiet -O - get.pharo.org | bash >>>>> for the current stable release of Pharo and the PharoVM. >>>>> >>>>> On 2013-04-01, at 22:52, Tudor Girba wrote: >>>>>> No stress. In the worst case you can fix it tomorrow during the tutorial >>>>>> :). >>>>>> >>>>>> Doru >>>>>> >>>>>> >>>>>> On Apr 1, 2013, at 10:26 PM, Camillo Bruni >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> On 2013-04-01, at 22:09, "Sean P. DeNigris" >>>>>>> wrote: >>>>>>> >>>>>>>> Tudor Girba-2 wrote >>>>>>>>> Could it have something to do with the latest optimizations of >>>>>>>>> Camillo? >>>>>>>> >>>>>>>> Probably... Cami breaks everything :-P >>>>>>> >>>>>>> dammit, I wanted to silently add the new zeroconf scripts >>>>>>> obviously something went horribly wrong there, sorry guys.. working on >>>>>>> it! >>>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "What is more important: To be happy, or to make happy?" >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > >
Re: [Pharo-project] [3.0] CI build is broken
Another attempt. Norbert vm-ui.sh Description: Binary data Am 02.04.2013 um 10:43 schrieb Norbert Hartl : > Ah, rats, didn't think it through. It only works for commandline switches > that do not have an argument itself. Sad and sorry! > > Norbert > > Am 02.04.2013 um 10:38 schrieb Norbert Hartl : > >> Very good Cami. I have two remarks. If it should be short I think that >> >> curl -sL get.pharo.org | bash >> >> is shorter than >> >> wget --quiet -O - get.pharo.org | bash >> >> If I see it correct the script is used for CI but as there is a >> get.pharo.org host I assume it is supposed to be an easy entry point for all >> kind of users, right? >> >> If this is true I find it somewhat strange to have a >> download-all-in-one-and-cozy-script that downloads everything needed but to >> start it I have still to provide the image myself to the shell scripts. So I >> added this to the script >> >> # parse vm options and image >> for arg in "$@" >> do >> if [[ $arg == -* ]]; >> then >> VMOPTIONS="$VMOPTIONS $arg" >> shift >> else >> break >> fi >> done >> IMAGE=$1 >> shift >> # if no image has been provided use the installed one >> if [ -z "$IMAGE" ]; >> then >> IMAGE=$DIR/Pharo.image >> fi >> >> which uses the downloaded image in case nothing has been specified on the >> commandline. >> >> Hope you like it. Usually I would extract the same portion of both scripts >> to an extra file but then there is the trade-off to have one more file in >> the download. I'll attach a version of vm-ui.sh for you to try. If you need >> help I'm happy to chime in for this. >> >> thanks for the effort, >> >> Norbert >> >> >> >> Am 02.04.2013 um 09:15 schrieb Camillo Bruni : >> >>> we're back up, shinier than ever ;) >>> >>> check http://get.pharo.org ;) >>> >>> now you can use: >>> wget --quiet -O - get.pharo.org | bash >>> for the current stable release of Pharo and the PharoVM. >>> >>> On 2013-04-01, at 22:52, Tudor Girba wrote: >>>> No stress. In the worst case you can fix it tomorrow during the tutorial >>>> :). >>>> >>>> Doru >>>> >>>> >>>> On Apr 1, 2013, at 10:26 PM, Camillo Bruni wrote: >>>> >>>>> >>>>> On 2013-04-01, at 22:09, "Sean P. DeNigris" wrote: >>>>> >>>>>> Tudor Girba-2 wrote >>>>>>> Could it have something to do with the latest optimizations of Camillo? >>>>>> >>>>>> Probably... Cami breaks everything :-P >>>>> >>>>> dammit, I wanted to silently add the new zeroconf scripts >>>>> obviously something went horribly wrong there, sorry guys.. working on it! >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "What is more important: To be happy, or to make happy?" >>>> >>>> >>> >>> >> > >
Re: [Pharo-project] [3.0] CI build is broken
Ah, rats, didn't think it through. It only works for commandline switches that do not have an argument itself. Sad and sorry! Norbert Am 02.04.2013 um 10:38 schrieb Norbert Hartl : > Very good Cami. I have two remarks. If it should be short I think that > > curl -sL get.pharo.org | bash > > is shorter than > > wget --quiet -O - get.pharo.org | bash > > If I see it correct the script is used for CI but as there is a get.pharo.org > host I assume it is supposed to be an easy entry point for all kind of users, > right? > > If this is true I find it somewhat strange to have a > download-all-in-one-and-cozy-script that downloads everything needed but to > start it I have still to provide the image myself to the shell scripts. So I > added this to the script > > # parse vm options and image > for arg in "$@" > do > if [[ $arg == -* ]]; > then > VMOPTIONS="$VMOPTIONS $arg" > shift > else > break > fi > done > IMAGE=$1 > shift > # if no image has been provided use the installed one > if [ -z "$IMAGE" ]; > then > IMAGE=$DIR/Pharo.image > fi > > which uses the downloaded image in case nothing has been specified on the > commandline. > > Hope you like it. Usually I would extract the same portion of both scripts to > an extra file but then there is the trade-off to have one more file in the > download. I'll attach a version of vm-ui.sh for you to try. If you need help > I'm happy to chime in for this. > > thanks for the effort, > > Norbert > > > > Am 02.04.2013 um 09:15 schrieb Camillo Bruni : > >> we're back up, shinier than ever ;) >> >> check http://get.pharo.org ;) >> >> now you can use: >> wget --quiet -O - get.pharo.org | bash >> for the current stable release of Pharo and the PharoVM. >> >> On 2013-04-01, at 22:52, Tudor Girba wrote: >>> No stress. In the worst case you can fix it tomorrow during the tutorial :). >>> >>> Doru >>> >>> >>> On Apr 1, 2013, at 10:26 PM, Camillo Bruni wrote: >>> >>>> >>>> On 2013-04-01, at 22:09, "Sean P. DeNigris" wrote: >>>> >>>>> Tudor Girba-2 wrote >>>>>> Could it have something to do with the latest optimizations of Camillo? >>>>> >>>>> Probably... Cami breaks everything :-P >>>> >>>> dammit, I wanted to silently add the new zeroconf scripts >>>> obviously something went horribly wrong there, sorry guys.. working on it! >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "What is more important: To be happy, or to make happy?" >>> >>> >> >> >
Re: [Pharo-project] [3.0] CI build is broken
Very good Cami. I have two remarks. If it should be short I think that curl -sL get.pharo.org | bash is shorter than wget --quiet -O - get.pharo.org | bash If I see it correct the script is used for CI but as there is a get.pharo.org host I assume it is supposed to be an easy entry point for all kind of users, right? If this is true I find it somewhat strange to have a download-all-in-one-and-cozy-script that downloads everything needed but to start it I have still to provide the image myself to the shell scripts. So I added this to the script # parse vm options and image for arg in "$@" do if [[ $arg == -* ]]; then VMOPTIONS="$VMOPTIONS $arg" shift else break fi done IMAGE=$1 shift # if no image has been provided use the installed one if [ -z "$IMAGE" ]; then IMAGE=$DIR/Pharo.image fi which uses the downloaded image in case nothing has been specified on the commandline. Hope you like it. Usually I would extract the same portion of both scripts to an extra file but then there is the trade-off to have one more file in the download. I'll attach a version of vm-ui.sh for you to try. If you need help I'm happy to chime in for this. thanks for the effort, Norbert vm-ui.sh Description: Binary data Am 02.04.2013 um 09:15 schrieb Camillo Bruni : > we're back up, shinier than ever ;) > > check http://get.pharo.org ;) > > now you can use: > wget --quiet -O - get.pharo.org | bash > for the current stable release of Pharo and the PharoVM. > > On 2013-04-01, at 22:52, Tudor Girba wrote: >> No stress. In the worst case you can fix it tomorrow during the tutorial :). >> >> Doru >> >> >> On Apr 1, 2013, at 10:26 PM, Camillo Bruni wrote: >> >>> >>> On 2013-04-01, at 22:09, "Sean P. DeNigris" wrote: >>> Tudor Girba-2 wrote > Could it have something to do with the latest optimizations of Camillo? Probably... Cami breaks everything :-P >>> >>> dammit, I wanted to silently add the new zeroconf scripts >>> obviously something went horribly wrong there, sorry guys.. working on it! >>> >> >> -- >> www.tudorgirba.com >> >> "What is more important: To be happy, or to make happy?" >> >> > >
Re: [Pharo-project] I stumbled upon
Am 30.03.2013 um 20:19 schrieb stephane ducasse : > Did you check what are the senders of first:? I don't. But I can imagine there are loads of senders of next: :) Same case, no? Norbert
Re: [Pharo-project] Versionner in pharo 2.0
Hi, I fixed the announcements already and got to the metacello toolbox problems. It is complaining a version (actually a baseline version) does not exist although it is defined in the configuration. If you are on it I'm happy to shy away. My time frame for it is over anyway. Just to let you know that you have one lucky customer for anything you'll achieve. Let me know! Norbert Am 28.03.2013 um 13:58 schrieb Christophe Demarey : > Hi Norbert, > > Here is a patch for announcements (and some other things) for Versionner on > Pharo2. Unzip, add this folder as repository in Monticello and load latest > packages versions. > After that, I'm not sure it will help you because there are issues with > MetacelloToolbox. > I'm working on that and I hope to have good news soon. > > Regards, > Christophe. > > > > > Le 28 mars 2013 à 12:44, Esteban Lorenzano a écrit : > >> Hi Norbert, >> >> Check around SystemAnnouncer :) >> >> Esteban >> >> On Mar 28, 2013, at 12:37 PM, Norbert Hartl wrote: >> >>> Can you tell me what an equivalent to a SystemChangeNotifier call would be >>> today? I can derive Announcement class names from the message sends to >>> SystemChangeNotifier. But I don't know e.g. where is the announcer in the >>> system where you would register for class change, method modified etc. >>> announcements. >>> >>> Norbert >>> >>> Am 28.03.2013 um 11:51 schrieb Esteban Lorenzano : >>> >>>> there is work in progress... a bit slow because my times (and Christoph's) >>>> are a bit... overcharged :) >>>> >>>> On Mar 28, 2013, at 11:17 AM, Norbert Hartl wrote: >>>> >>>>> Is there work in progress to make Versionner work in pharo 2.0? The >>>>> problems I see are at first related to the removal SystemChangeNotifier. >>>>> If nobody is working on it is there any reading material about the >>>>> changes from SystemChangeNotifier to Announcements? I could fix it myself >>>>> then but I don't know nothing about this system internal. >>>>> >>>>> thanks, >>>>> >>>>> Norbert >>>> >>>> >>> >>> >> >> >
Re: [Pharo-project] Multiselect in method pane
https://pharo.fogbugz.com/f/cases/10162/multiple-selection-of-methods-in-method-pane-if-CompiledMethods-are-equal Norbert Am 28.03.2013 um 13:02 schrieb Camillo Bruni : > please! :) that would save some major pain here and there ;) > > On 2013-03-28, at 12:57, Benjamin > wrote: > >> if it works go ahead ;) >> >> Ben >> >> On Mar 28, 2013, at 12:48 PM, Norbert Hartl wrote: >> >>> >>> Am 28.03.2013 um 11:51 schrieb stephane ducasse : >>> >>>> >>>> On Mar 28, 2013, at 11:21 AM, Norbert Hartl wrote: >>>> >>>>> What is the rationale for having the method pane as multi-select list? I >>>>> don't think it is of greater use when editing code. I could imagine that >>>>> some refactoring tasks could be easier having multi-select lists. >>>>> >>>>> Anyway, if I try to rename a method without using the refactoring engine >>>>> I just change the selector, save and delete the method with the old >>>>> selector. In pharo 2.0 when you rename a method and then click on the old >>>>> selector both methods are selected and shortcut invocation for deleting >>>>> deletes both. Which is quite annoying. In my opinion there is no reason >>>>> for two methods being selected. If you agree I'll happily enter a bug. >>>> >>>> >>>> The problem is not a nautilus bug but a compiled method one if I remember >>>> correctly. >>>> because two methods with the same body are equal. >>>> >>> It happens in MethodWidget>>#methodSelectionAt:put. When >>> PluggableIconListMorph updates the list selection it calls the MethodWidget >>> to set true on the new method selected. But MethodWidget uses a Dictionary >>> for instVar methodSelection and finds the old method being equal and >>> enables this. >>> As I don't see a reason why a selection should be done by equality this >>> behavior can be fixed by using an IdentityDictionary. >>> >>> Fix: >>> >>> MethodWidget>>#initialize >>> >>> super initialize. >>> methodsSelection := IdentityDictionary new. >>> >>> Any arguments? >>> >>> Norbert >> > >
Re: [Pharo-project] Multiselect in method pane
Am 28.03.2013 um 11:51 schrieb stephane ducasse : > > On Mar 28, 2013, at 11:21 AM, Norbert Hartl wrote: > >> What is the rationale for having the method pane as multi-select list? I >> don't think it is of greater use when editing code. I could imagine that >> some refactoring tasks could be easier having multi-select lists. >> >> Anyway, if I try to rename a method without using the refactoring engine I >> just change the selector, save and delete the method with the old selector. >> In pharo 2.0 when you rename a method and then click on the old selector >> both methods are selected and shortcut invocation for deleting deletes both. >> Which is quite annoying. In my opinion there is no reason for two methods >> being selected. If you agree I'll happily enter a bug. > > > The problem is not a nautilus bug but a compiled method one if I remember > correctly. > because two methods with the same body are equal. > It happens in MethodWidget>>#methodSelectionAt:put. When PluggableIconListMorph updates the list selection it calls the MethodWidget to set true on the new method selected. But MethodWidget uses a Dictionary for instVar methodSelection and finds the old method being equal and enables this. As I don't see a reason why a selection should be done by equality this behavior can be fixed by using an IdentityDictionary. Fix: MethodWidget>>#initialize super initialize. methodsSelection := IdentityDictionary new. Any arguments? Norbert
Re: [Pharo-project] Versionner in pharo 2.0
Can you tell me what an equivalent to a SystemChangeNotifier call would be today? I can derive Announcement class names from the message sends to SystemChangeNotifier. But I don't know e.g. where is the announcer in the system where you would register for class change, method modified etc. announcements. Norbert Am 28.03.2013 um 11:51 schrieb Esteban Lorenzano : > there is work in progress... a bit slow because my times (and Christoph's) > are a bit... overcharged :) > > On Mar 28, 2013, at 11:17 AM, Norbert Hartl wrote: > >> Is there work in progress to make Versionner work in pharo 2.0? The problems >> I see are at first related to the removal SystemChangeNotifier. >> If nobody is working on it is there any reading material about the changes >> from SystemChangeNotifier to Announcements? I could fix it myself then but I >> don't know nothing about this system internal. >> >> thanks, >> >> Norbert > >
Re: [Pharo-project] Multiselect in method pane
Am 28.03.2013 um 11:51 schrieb stephane ducasse : > > On Mar 28, 2013, at 11:21 AM, Norbert Hartl wrote: > >> What is the rationale for having the method pane as multi-select list? I >> don't think it is of greater use when editing code. I could imagine that >> some refactoring tasks could be easier having multi-select lists. >> >> Anyway, if I try to rename a method without using the refactoring engine I >> just change the selector, save and delete the method with the old selector. >> In pharo 2.0 when you rename a method and then click on the old selector >> both methods are selected and shortcut invocation for deleting deletes both. >> Which is quite annoying. In my opinion there is no reason for two methods >> being selected. If you agree I'll happily enter a bug. > > > The problem is not a nautilus bug but a compiled method one if I remember > correctly. > because two methods with the same body are equal. Ok, so my case is an edge case which usually doesn't happen. But what is the rationale for selecting based on equality instead of identity? Norbert
[Pharo-project] Multiselect in method pane
What is the rationale for having the method pane as multi-select list? I don't think it is of greater use when editing code. I could imagine that some refactoring tasks could be easier having multi-select lists. Anyway, if I try to rename a method without using the refactoring engine I just change the selector, save and delete the method with the old selector. In pharo 2.0 when you rename a method and then click on the old selector both methods are selected and shortcut invocation for deleting deletes both. Which is quite annoying. In my opinion there is no reason for two methods being selected. If you agree I'll happily enter a bug. Norbert
[Pharo-project] Versionner in pharo 2.0
Is there work in progress to make Versionner work in pharo 2.0? The problems I see are at first related to the removal SystemChangeNotifier. If nobody is working on it is there any reading material about the changes from SystemChangeNotifier to Announcements? I could fix it myself then but I don't know nothing about this system internal. thanks, Norbert
Re: [Pharo-project] [Pharo-users] in anybody out there? who uses 2.0?
Am 27.03.2013 um 15:24 schrieb Esteban Lorenzano : > Hi, > > Here in Pharo headquarters we are shock that there are just 10 new bugs > reported for 2.0 after the release... > So... I wonder... is that because we made a really cool release, or just > because nobody is using it? > Most of my stuff is still on 1.4. As there is no big reason to move, I don't move because it takes time I can't spend at the moment. It will take some time to get used to the new environment, too. That means I need to figure out how to reestablish most of the 1.4 behavior (keyboard shortcuts, etc..) first. I will move on a project by project basis to 2.0 and for the time I need to work in a mixed environment I'm not ready to use two different UI/keyboard/mouse/whatever systems. So mimicking 1.4 behavior in 2.0 is first and getting used to the new ways comes after. Getting used to new things does not include keyboard shortcuts. I don't like them and I fear the day the support for 1.x shortcuts will be treated as legacy burden. It's just that there are people that hate emacs and everything that is like it :) But I'm in progress to move a project to 2.0. We'll see! Norbert
Re: [Pharo-project] Some issues with UDP sockets in Pharo 1.4/Pharo 2.0
Am 27.03.2013 um 11:31 schrieb Sven Van Caekenberghe : > Semantically, datagrams can get lost or arrive out of order. A or B will > never know as there are no guarantees. To add reliability, you need > acknowledgements, retries, numbering, and so on. If you do all that with a > stream interface, you are building your own TCP layer. Yes, but using a stream does not necessarily mean that the transport is reliable. It can still be a stream of (modern speak) "eventually consistent" transport :) I think we discussed it thoroughly and didn't want to hijack the original post. Norbert
Re: [Pharo-project] Some issues with UDP sockets in Pharo 1.4/Pharo 2.0
Am 27.03.2013 um 00:25 schrieb Sven Van Caekenberghe :
>
> On 26 Mar 2013, at 23:46, Norbert Hartl wrote:
>
>> Am 26.03.2013 um 21:08 schrieb Sven Van Caekenberghe :
>>
>>> Hi Holger,
>>>
>>> On 26 Mar 2013, at 12:12, Holger Hans Peter Freyther
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I am porting a tooling class that I wrote on GST for my SIP and MGCP code
>>>> to Pharo. This class will create a socket and then fork a RX and TX
>>>> process.
>>>> I have some issues with 'stopping' the socket. I have created an example
>>>> that shows the issue in Pharo 2.0 and Pharo 1.4 with the pharovm (and to
>>>> have more debug output with a re-compiled one).
>>>>
>>>>
>>>>| s rx |
>>>>s := Socket newUDP.
>>>>rx := [
>>>>[s waitForData. s halt]
>>>>on: ConnectionClosed do: [ s halt]
>>>>] fork.
>>>>"Wait for the process to hit the readSemaphore"
>>>>(Delay forSeconds: 3) wait.
>>>>s close.
>>>>
>>>>
>>>> My expectation is that I will get the ConnectionClosed signal or at least
>>>> that >>#waitForData will return once the socket is closed. This is based
>>>> on reading the comment of >>#waitForData.
>>>>
>>>>
>>>> The Socket>>#waitForData documentation reads like this:
>>>>"Wait for data to arrive. This method will block until
>>>>data is available or the socket is closed. If the socket is closed
>>>>a ConnectionClosed exception will be signaled."
>>>>
>>>>
>>>> I had a look at the socket plugin and the following is happening. First
>>>> aio is disabled, the state set to ThisEndClosed, then ::close is called
>>>> and in the above case the result is '0' and the following code will be
>>>> executed:
>>>>
>>>> else if (0 == result)
>>>> {
>>>>/* close completed synchronously */
>>>>SOCKETSTATE(s)= Unconnected;
>>>>FPRINTF((stderr, "closeConnection: disconnected\n"));
>>>>SOCKET(s)= -1;
>>>> }
>>>>
>>>>
>>>> this means that my 'rx' process will happily wait on the readSemaphore
>>>> of the Socket and will never be woken up.
>>>>
>>>>
>>>> My question are probably:
>>>>
>>>> 1.) Is this the intended behavior for Socket>>#close and
>>>> Socket>>#waitForData?
>>>> 2.) How should I terminate my RX process?
>>>>
>>>> kind regards
>>>>holger
>>>>
>>>> PS: The issue is probably socket specific and not related to UDP.
>>>
>>> Maybe I am telling you things you already know, but TCP and UDP are
>>> fundamentally different. UDP is really one-shot, try-and-hope, completely
>>> asynchronous. In networking you generally only get a ConnectionClosed when
>>> you actually read or write (and even then ;-).
>>>
>> That's not really true. It is implementation specific. IMHO you can open a
>> UDP socket in send and receive mode where the communication is synchronous.
>> So your socket blocks until a datagram socket is received. This has to
>> advantage that the underlying OS registers local and remote port and
>> automatically and accepts only datagrams for the right ports match. As it is
>> in a lot of use cases not preferrable to have blocking sockets while using
>> UDP you use two sockets instead, one for sending and one for receiving. For
>> this you need to register the listening socket for listening to everything.
>> Disclaimer: I took this from the back of my head and this might by
>> outdated/inproper information. I just wanted to say that you shouldn't mix
>> asynchronous with unidirectional :)
>>
>> Norbert
>
> I politely disagree ;-)
>
> But I am willing to learn: so please provide some references of such UDP
> usage.
>
> http://en.wikipedia.org/wiki/Datagram
>
If I find the time I dig out some things from the past. I just can't follow
your reasoning that the way UDP is defined means unidirectional. TCP defines a
connection, UDP does not. Connections are not required to have end-to-end
communication. A remote port is a service identifier and local port is a client
identifier. A port pair defines a communication channel. TCP just adds roles to
both ends and defines stream sequences and transmission windows.
Maybe I misunderstood you then I take everything back :)
Norbert
>>> The Socket API has many strange methods, most of which you should not
>>> touch. You should use SocketStream. Looking in the VM code is also
>>> misleading because the 3 platforms (Mac, Win, *nix) are different. In
>>> Socket[Stream] there is lots of historic baggage.
>>>
>>> I would suggest you look at Smalltalk code that actually works (for TCP,
>>> Zinc Client and Server code would do, for UDP, ZTimestampSNTPClient for
>>> example).
>>>
>>> For your concrete question (2): just start a reading process, wrap it in a
>>> handler and clean up. For UDP this will never happen: you will keep on
>>> reading nothing. For TCP reading will eventually fail if the other end
>>> disappears.
>>>
>>> HTH,
>>>
>>> Sven
>>>
>>> --
>>> Sven Van Caekenberghe
>>> http://stfx.eu
>>> Smalltalk is the Red Pill
>>>
>>>
>>
>>
>
>
Re: [Pharo-project] Some issues with UDP sockets in Pharo 1.4/Pharo 2.0
Am 26.03.2013 um 21:08 schrieb Sven Van Caekenberghe :
> Hi Holger,
>
> On 26 Mar 2013, at 12:12, Holger Hans Peter Freyther
> wrote:
>
>> Hi,
>>
>> I am porting a tooling class that I wrote on GST for my SIP and MGCP code
>> to Pharo. This class will create a socket and then fork a RX and TX process.
>> I have some issues with 'stopping' the socket. I have created an example
>> that shows the issue in Pharo 2.0 and Pharo 1.4 with the pharovm (and to
>> have more debug output with a re-compiled one).
>>
>>
>> | s rx |
>> s := Socket newUDP.
>> rx := [
>> [s waitForData. s halt]
>> on: ConnectionClosed do: [ s halt]
>> ] fork.
>> "Wait for the process to hit the readSemaphore"
>> (Delay forSeconds: 3) wait.
>> s close.
>>
>>
>> My expectation is that I will get the ConnectionClosed signal or at least
>> that >>#waitForData will return once the socket is closed. This is based
>> on reading the comment of >>#waitForData.
>>
>>
>> The Socket>>#waitForData documentation reads like this:
>> "Wait for data to arrive. This method will block until
>> data is available or the socket is closed. If the socket is closed
>> a ConnectionClosed exception will be signaled."
>>
>>
>> I had a look at the socket plugin and the following is happening. First
>> aio is disabled, the state set to ThisEndClosed, then ::close is called
>> and in the above case the result is '0' and the following code will be
>> executed:
>>
>> else if (0 == result)
>>{
>> /* close completed synchronously */
>> SOCKETSTATE(s)= Unconnected;
>> FPRINTF((stderr, "closeConnection: disconnected\n"));
>> SOCKET(s)= -1;
>>}
>>
>>
>> this means that my 'rx' process will happily wait on the readSemaphore
>> of the Socket and will never be woken up.
>>
>>
>> My question are probably:
>>
>> 1.) Is this the intended behavior for Socket>>#close and
>> Socket>>#waitForData?
>> 2.) How should I terminate my RX process?
>>
>> kind regards
>> holger
>>
>> PS: The issue is probably socket specific and not related to UDP.
>
> Maybe I am telling you things you already know, but TCP and UDP are
> fundamentally different. UDP is really one-shot, try-and-hope, completely
> asynchronous. In networking you generally only get a ConnectionClosed when
> you actually read or write (and even then ;-).
>
That's not really true. It is implementation specific. IMHO you can open a UDP
socket in send and receive mode where the communication is synchronous. So your
socket blocks until a datagram socket is received. This has to advantage that
the underlying OS registers local and remote port and automatically and accepts
only datagrams for the right ports match. As it is in a lot of use cases not
preferrable to have blocking sockets while using UDP you use two sockets
instead, one for sending and one for receiving. For this you need to register
the listening socket for listening to everything.
Disclaimer: I took this from the back of my head and this might by
outdated/inproper information. I just wanted to say that you shouldn't mix
asynchronous with unidirectional :)
Norbert
> The Socket API has many strange methods, most of which you should not touch.
> You should use SocketStream. Looking in the VM code is also misleading
> because the 3 platforms (Mac, Win, *nix) are different. In Socket[Stream]
> there is lots of historic baggage.
>
> I would suggest you look at Smalltalk code that actually works (for TCP, Zinc
> Client and Server code would do, for UDP, ZTimestampSNTPClient for example).
>
> For your concrete question (2): just start a reading process, wrap it in a
> handler and clean up. For UDP this will never happen: you will keep on
> reading nothing. For TCP reading will eventually fail if the other end
> disappears.
>
> HTH,
>
> Sven
>
> --
> Sven Van Caekenberghe
> http://stfx.eu
> Smalltalk is the Red Pill
>
>
Re: [Pharo-project] fog monkey bugz
Am 25.03.2013 um 10:25 schrieb Benjamin : > For me, there is this user > > NorbertHartl > norb...@hartl.name > > (with even a picture, so I think you already had an account an forgot about > it maybe ^^) > Well, the picture is from gravatar and will show up everywhere I use the same email address :) I don't have a glue why the account existed already. And there wasn't a notice when entering via bugs.pharo.org. Well, in the meantime I was smart enough to find the "forgot password" feature. Everything's fine now, thanks. Norbert > If you want I can set you a new password > Ben > > On Mar 25, 2013, at 10:20 AM, Norbert Hartl wrote: > >> Yesterday I registered for an account on bugs.pharo.org. I enteres username >> (NorbertHartl) and email and assured I'm not monkey. I got to the fogbugz >> page but not logged in. I didn't receive an email to set a password or >> something like that. How is it supposed to work? >> >> Norbert >
[Pharo-project] fog monkey bugz
Yesterday I registered for an account on bugs.pharo.org. I enteres username (NorbertHartl) and email and assured I'm not monkey. I got to the fogbugz page but not logged in. I didn't receive an email to set a password or something like that. How is it supposed to work? Norbert
Re: [Pharo-project] [pharo website] updated the issue tracking page
Am 24.03.2013 um 16:58 schrieb Marcus Denker : > > On Mar 24, 2013, at 4:56 PM, Norbert Hartl wrote: > >> >> Am 24.03.2013 um 16:49 schrieb Marcus Denker : >> >>> >>> On Mar 24, 2013, at 4:46 PM, Norbert Hartl wrote: >>> >>>> >>>> Am 24.03.2013 um 16:29 schrieb Marcus Denker : >>>> >>>>> Hi, >>>>> >>>>> I updated this page: >>>>> >>>>> http://www.pharo-project.org/community/issue-tracking >>>>> >>>> >>>> The last link on the page >>>> >>>> The best thing is to just do it. The list is here. >>>> >>>> points to google tracker. >>> >>> Thanks! I fixed it by removing it ;-) >>> >>> >> Ok, then how would you fix that >> >> bugs.pharo-project.org >> >> points to the google tracker? Let me guess! :) >> > > The problem is that for pharo-project.org I need to bug someone else. > And in additon, having everything double is annoying. > > In the medium term, I would like to move everything to use the domain > pharo.org > > I will send a mail for changing bugs.pharo-project.org... > I guess there are links that use it. If you want to settle that issue for the time being make bugs.pharo-project.org a CNAME to bugs.pharo.org. Norbert
Re: [Pharo-project] [pharo website] updated the issue tracking page
Am 24.03.2013 um 16:49 schrieb Marcus Denker : > > On Mar 24, 2013, at 4:46 PM, Norbert Hartl wrote: > >> >> Am 24.03.2013 um 16:29 schrieb Marcus Denker : >> >>> Hi, >>> >>> I updated this page: >>> >>> http://www.pharo-project.org/community/issue-tracking >>> >> >> The last link on the page >> >> The best thing is to just do it. The list is here. >> >> points to google tracker. > > Thanks! I fixed it by removing it ;-) > > Ok, then how would you fix that bugs.pharo-project.org points to the google tracker? Let me guess! :) Norbert
Re: [Pharo-project] [pharo website] updated the issue tracking page
Am 24.03.2013 um 16:29 schrieb Marcus Denker : > Hi, > > I updated this page: > > http://www.pharo-project.org/community/issue-tracking > The last link on the page The best thing is to just do it. The list is here. points to google tracker. Norbert
Re: [Pharo-project] Petit parser UI
Am 21.03.2013 um 11:21 schrieb Tudor Girba : > Hi Norbert, > > Indeed, this was one of the main new additions to Moose. Lukas helped with > the refactoring support and I rebuilt the browser to show that you can have a > Glamour browser without and explicit UI model. It seems that it works :). > > I am happy you like it. The point about variables is a good one. Could you > please add it to the Moose issue tracker? https://code.google.com/p/moose-technology/issues/detail?id=920 > > But, I think it can still be improved further. The goal is to have the > developer only use this browser during development, without needing the Pharo > system browser. We are almost there, but not quite. > > In general, I am interested in any experience of using the browser and in > learning when it falls short and makes you have to use the system browser. > > One thing that is utterly missing is the support for testing. PetitParser > comes with a beautiful support for tests and I would like to bring these > tests close to the productions. > Those sound like good ideas. In my case it was a debugging issue. I needed to go back to my grammar and look why certain snippets cannot be parsed. So avoiding the system browser isn't the right goal here. What helped is the separation of example text and matching pane. Switching to the debugger was very helpful because the grammar is utterly complex and I don't know what something is meant to be most of the time. In the debugger you can follow the parsing and figure out easily what has been matched. That is even the way I developed my test cases. I don't have a repository for productions and test data. So I took live data followed the debugger and his matches. From that I verified things by hand and then I did a test case for it. I was missing an inspector that gives me an inspector of the parsed model but I found it while writing the first mail :) Norbert > > On Mar 21, 2013, at 9:54 AM, Norbert Hartl wrote: > >> Whoever changed petit parser UI in the last couple month: Very good job! >> After some time working in a new image with new versions I opened the UI and >> was very pleased that most of the things I was missing in the old UI are >> there now. >> >> To me there is less to improve…wait….maybe two little things: >> >> - The pane that lets you choose the production rule shows all instance >> variables of the selected parser class. In case I have a derived parser >> class where not every selector is overwritten I don't have a chance to >> select the rule. Would it be a good to show all instance variables of all >> class in the hierarchy above the petit parser classes? >> - Applying the … … what's that "i" button above the lower right pane? Haha, >> just found what I was looking for. Screw that point. Make it one little >> thing! >> >> Norbert >> >> > > -- > www.tudorgirba.com > > "Don't give to get. Just give." > > > > > >
[Pharo-project] Petit parser UI
Whoever changed petit parser UI in the last couple month: Very good job! After some time working in a new image with new versions I opened the UI and was very pleased that most of the things I was missing in the old UI are there now. To me there is less to improve…wait….maybe two little things: - The pane that lets you choose the production rule shows all instance variables of the selected parser class. In case I have a derived parser class where not every selector is overwritten I don't have a chance to select the rule. Would it be a good to show all instance variables of all class in the hierarchy above the petit parser classes? - Applying the … … what's that "i" button above the lower right pane? Haha, just found what I was looking for. Screw that point. Make it one little thing! Norbert
Re: [Pharo-project] [Pharo-users] [ANN] Pharo 2.0
Congrats! Norbert Am 18.03.2013 um 11:12 schrieb Marcus Denker : > We are proud to announce the release of Pharo 2.0! > > You can find information about Pharo at: http://www.pharo-project.org > > > About this release > -- > All in all, there were over 1600 issues treated in the issue tracker > and 1350 improvements integrated into 2.0. > > http://code.google.com/p/pharo/issues/list?can=1&q=Milestone%3D2.0+status%3AIntegrated > > Read it again, yes 1350 is huge, take two minutes and have a look at the list > of > improvements! Now you got the feel of the effort. And this was a true > community > effort. It is possible because people worldwide helped! We want to deeply > thank them. > > We want to thank Inria for its constant support, in particular for the salary > of Igor > Stasenko and Esteban Lorenzano, and for the help in the infrastructure. > > We have accomplished this huge task for a better system because we were > together. Do not > forget that we are working on a consortium to support our system: > > - http://consortium.pharo.org (for companies and organizations) > - http://association.pharo.org (for individuals) > > Our goal is to build a system so that we can make a living with our > creativity and > programming skills. > > You can find information about Pharo on http://www.pharo-project.org. In > particular, > you may be interested in: > > - Joining us and getting help http://www.pharo-project.org/community > - Getting the Pharo By Example book (available as a free PDF): > http://www.pharobyexample.org > - Watching the screencasts http://www.pharocasts.com > - Reporting problems http://www.pharo-project.org/community/issue-tracking > - Reading the forth coming book http://rmod.lille.inria.fr/pbe2 > - Reading the Pharo vision document http://bit.ly/HNkEru > > Thanks a lot for your participation, energy and fun. > > -- The Pharo Team > > Summarized issues for 2.0 > == > > UI > --- > > - Spec > - Widget enhancements > - Layout improvements/cleanups > - Keybindings > - New icons (famfam) > - Growl style notifications > - Revamp progress bar > > Developer tools > --- > > - Nautilus browser > - Critics browser > - Improved version diff browsing > - Spotlight > - Revamp Code Completion and smart chars > - Interactive navigation using ctrl/cmd+click over classes/methods > - Shout themes > - Andreas profiler > > Networking > --- > > - Update Zinc > - Zodiac (SSL) > > System > --- > > - System Announcer > - RPackage replacing PackageInfo > - Command line tools / Headless mode > - Native boost > - Update Ring metamodel > - Fuel serializer > - Freetype fonts > > Kernel > -- > > - DateAndTime refactoring > - Updated FileSystem and replaced FileDirectory > > VM > -- > > - Latests cog builds > - SSLPlugin > - FilePlugin enhancements > - SocketPlugin fixes > - Included libraries: freetype2, cairo > > Cleanups > - > > - FileDirectory removed (replaced by FileSystem) > - SmartRefStream and ReferenceStream removed (replaced by Fuel) > - PackageInfo deprecated (replaced by RPackage) > > Other > --- > > - Zeroconf scripts > - Continuous Integration for every aspect of our release process. > > Not all the changes are reported here, but this is to give you an impression, > you can find better explanation here: > https://code.google.com/p/pharo/wiki/ActionsInPharo20 > > >
Re: [Pharo-project] [Pharo-users] about communication and collaboration
that's great! Another missing piece of the infrastructure! Nobert Am 12.03.2013 um 16:02 schrieb Stéphane Ducasse : > Dear Pharoers > > last january I visited another lab and I realised that the Pharo Team was not > good at systematically telling what we were doing. > I got quite frustrated by that situation, especially because we are working > hard to build a better system. > So we brainstormed when I came back and we want to apply the same ideas that > what we do for our research team. > > For our research team every monday we get a simple mail that tell us to say > to the others what we did and what we > plan to do. Simple, easy. > Then after people of the rmod team can discuss if they want more. > > We want to do the same with pharo. > Often this is not that we are not doing things. Often we are doing boring, > tedious stupid but $^%&&*^ important tasks and we want that you know it. > In addition we want to share on what we are weekly working. So that you can > be more engaged to > join and collaborate with us. > > So we will launch an experience and see. For now we will send a notification > every two weeks. > > the Pharo Team
Re: [Pharo-project] Osmocom Smalltalk packages available/ (mobile) communication packages for Pharo
It is hol...@freyther.de Norbert Am 24.02.2013 um 11:47 schrieb stephane ducasse : > I would be nice to know if they can propose a dual licensing GPL / MIT. > But I could not find a way to contact the author. > > Sef > >> Found this on the web: >> >> http://smalltalk.gnu.org/blog/zecke/making-my-osmocom-smalltalk-packages-available-pharo >> > >
Re: [Pharo-project] Pharo in Debian
Am 22.02.2013 um 10:28 schrieb Sven Van Caekenberghe : > > On 22 Feb 2013, at 10:16, Damien Cassou wrote: > >> Hi Philippe, >> >> On Thu, Feb 21, 2013 at 10:19 PM, p...@highoctane.be >> wrote: >>> I don't have a clue about Debian packaging but as there is already >>> squeak, we may be able to reuse a bit. >> >> >> it would be great if you could have a look at that. > > Yes, that would indeed be super, but it is slightly more complicated than > that. > > In order to get your package into the official repositories, you need to > follow a lot of rules and processes, and it is quite slow and conservative > (months if not years), all to increase quality and stability. I am not sure > it matches well with Pharo's development velocity. > > The One-Click, the scripts that Camillo did or just a plain VM download with > basic documentation (like a read me ;-) are not that bad. We should make an > effort to improve what we have. > I don't see much of a reason to go for the official distribution. Debian is very special in that case and the last attempts to do it have shown that the two systems (debian and pharo) are no good match process wise. To the rescue there is launchpad [1] and PPAs (personal package archives). You can open a project in launchpad and make a PPA for your own package. The final installation instructions are somthing like sudo add-apt-repository ppa:LAUNCHPAD-USER/PPA-NAME and then sudo apt-get update sudo apt-get install PACKAGENAME I assume that the ease of installing is the main target and that you can get with PPA. my two cents, Norbert [1] https://launchpad.net/
Re: [Pharo-project] Pharo 2 changes management
Am 20.02.2013 um 11:34 schrieb Esteban Lorenzano : > > On Feb 20, 2013, at 11:25 AM, Norbert Hartl wrote: > >> >> Am 20.02.2013 um 11:17 schrieb Esteban Lorenzano : >> >>> there is a problem with the package definition, I think (PetitXPath != >>> Petitxpath), and new RPackage cannot detect they are the same... in fact, >>> IMO that exposes an old PackageInfo bug, not an RPackage problem, so I >>> think the real solution is to commit a package with a good package name. >> >> So, what are the rules. Does the case sensitivity also reflect in method >> extensions? Meaning do I need to call the extension *petitXPath or even >> *PetitXPath? > > nono, method extensions remains the same (case insensitive). What I mean is > that I made a mistake when I create the PetitXPath package originally (I > committed with a bad mc name)... that's the origin of your problem now (yep, > once again, my fault :). > But it shouldn't happen with other well-formed packages. And in my opinion, > best way to proceed is to create a package as it should be and re-commit, > because is not a MC problem, nor an RPackage problem, is a problem with that > specific package. > Hmm, can't get it to work. Now I have problems to get the method extensions into the package. Because of the Petitxpath being written lower case I had to remove the working copy. I created a new package with the letters in proper upper-/lowercase. The changes diff looks ok now but method extensions are not be part of the package. If I write the package and look at them use the "browse" button in monticello browser I can see that they are not included in the package. Norbert >> >>> Also, it does not looks like you have the lastest image... you should be >>> seeing something like this: >>> >> Yeah, I made the screenshot with an older image. I retried it then with >> updating the image first. But seeing that the result ist the same made me >> send the old screenshot. > > fiu... I was worried :) > > Esteban > >> Norbert >> >>> >>> >>> >>> (notice the diff morph has a bar in the middle, also two text label on top). >>> >>> >>> On Feb 20, 2013, at 11:08 AM, Norbert Hartl wrote: >>> >>>> I opened a fresh pharo 2 (#20559) and loaded PetitXPath. Modifying a >>>> method does not mark the package dirty in monticello browser. And If I >>>> press the "changes" button I can see >>>> >>>> >>>> >>>> That basically shows all the code that is in the package. But from my own >>>> change I cannot see anything in there. >>>> >>>> Norbert >>> >> >
Re: [Pharo-project] Pharo 2 changes management
Am 20.02.2013 um 11:17 schrieb Esteban Lorenzano : > there is a problem with the package definition, I think (PetitXPath != > Petitxpath), and new RPackage cannot detect they are the same... in fact, IMO > that exposes an old PackageInfo bug, not an RPackage problem, so I think the > real solution is to commit a package with a good package name. So, what are the rules. Does the case sensitivity also reflect in method extensions? Meaning do I need to call the extension *petitXPath or even *PetitXPath? > Also, it does not looks like you have the lastest image... you should be > seeing something like this: > Yeah, I made the screenshot with an older image. I retried it then with updating the image first. But seeing that the result ist the same made me send the old screenshot. Norbert > > > > (notice the diff morph has a bar in the middle, also two text label on top). > > > On Feb 20, 2013, at 11:08 AM, Norbert Hartl wrote: > >> I opened a fresh pharo 2 (#20559) and loaded PetitXPath. Modifying a method >> does not mark the package dirty in monticello browser. And If I press the >> "changes" button I can see >> >> >> >> That basically shows all the code that is in the package. But from my own >> change I cannot see anything in there. >> >> Norbert >
Re: [Pharo-project] Deploying without .changes and .sources files
Am 07.02.2013 um 10:06 schrieb Sven Van Caekenberghe : > SmalltalkImage > checkSourcesFileAvailability: false; > checkChangesFileAvailability: false. > > And then save the image. > If you are on stackoverflow I would prefer if you could post your answer there again. thanks, Norbert > On 07 Feb 2013, at 09:59, Damien Cassou wrote: > >> Hi, >> >> Norbert asked about the possibility to deploy a pharo image without >> .changes and .sources files >> >> http://stackoverflow.com/questions/14737695/is-it-possible-to-deploy-a-pharo-image-without-changes-and-sources-files >> >> Could people participate to the discussion there? I think it is important. >> >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." >> Winston Churchill >> > >
Re: [Pharo-project] Deploying without .changes and .sources files
Am 07.02.2013 um 10:08 schrieb Marcus Denker : > > On Feb 7, 2013, at 10:00 AM, Damien Cassou wrote: > >> Hi, >> >> Norbert asked about the possibility to deploy a pharo image without >> .changes and .sources files >> >> http://stackoverflow.com/questions/14737695/is-it-possible-to-deploy-a-pharo-image-without-changes-and-sources-files >> >> Could people participate to the discussion there? I think it is important. >> > > Stackoverflow is just one channel to much for me… I need to controll how this > or I will do nothing but > just read and filter. > Basically it is very easy. You can define the tags you are interested in and you can have a digest of that channel. So, I never look myself at stackoverflow but if a seaside, smalltalk, pharo,… question is asked I get an email. Not much to do there. For certain typical questions I find stackoverflow a good thing because it is kind of a faq/documentation site. Only in this regard I prefer it to the mailing lists. Norbert
Re: [Pharo-project] [ANN] NativeBoost project moved to new hosting: smalltalkhub
Am 31.01.2013 um 15:08 schrieb Igor Stasenko : > If you want to be added as developer(s) to > NativeBoost or AsmJit , make sure you are registered at smalltalkhub, > and then send me your credentials. This is a phishing mail. Official pharo members never ask you to give them your credentials. If you've done so please change your password immediately and notify the security department! Norbert
Re: [Pharo-project] I hate 'as yet unclassified'
Am 30.01.2013 um 22:03 schrieb Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com>:First, these are not categories. categories are for classes.These are protocols.Well, that's one reason I took the term "uncategorized". If I take the context menu in the category (!) pane I seeSo it looks to me that pharo has the notion of categories for organizing methods. A protocol is like an interface, or you can view it as servicesoffered by the instances of this class...For example take a look at Number you have'comparing', is a very generic service, so that any object can be in a setnumbers have this property to have full order, so they offer a bitmore than = and hash'printing' a very generic Object protocol too for interacting(inspectors, debuggers...)'arithmetic' is some more specialized service offered by numbers'mathematical functions' too.The category is a service for humans made by humans. The methods in e.g. "comparing" would work the same without a category. I think we can agree on the fact that relying on categories in code is mostly something not desirable. If the classification helps a lot, IMHO it's not only related to thenumber of messages.It helps to declare/discover which service will be offered, and thosecan be completely transversal (printing vs comparing).'private' has a value too, as there is no service to expect here...So I have to disagree. I see these as essentials.I did not decline that categories _can_ be useful and in fact they are. I'm also inclined to say that it is a good thing having all methods categorized in the distributed pharo image. So lint rules and such testing is good. But at the same time I don't see a point in enforcing it for everyone by choosing a stronger or even insulting term (at that point I decided to reply) for uncategorized methods. Norbert Nicolas2013/1/30 Norbert Hartl <norb...@hartl.name>:Am 29.01.2013 um 16:57 schrieb Stéphane Ducasse <stephane.duca...@inria.fr>:Hi guysI spend my time recategorizing methods.I would like the change the intention of 'as yet unclassified' because this is a PLAGUE.It is like throwing papers on the floor.So we should have a different name to indicate that it should be fixed.Any ideas?'you are a dirty programmer - change me'To be honest I have problems understanding why method categorization is so important. Often I don't care a single bit about categories because I don't understand them. I often categorize just to make lint happy :)What is the use? Declaring usage patterns? Declaring visibility? Use as method extensions marker? anything you like just classify? I can understand that it can help making the access of certain methods of a class easier. But that is particular true for classes with a lot of methods. Most of the classes are rather small. In most of my own developments I would consider most huge classes a design problem in my code. So I would try to fix that.And finally it is not easy to learn about them because the browser is not helping. If you browse through the methods of a class the category pane doesn't get updated. So even if I want to learn by getting used to them it is hard.I would make the none categorized term weaker by naming it "uncategorizied" so at least I have the change to deliberately not categorizing my methods without being annoyed by someones opinion about what is essential.my 2 cents,Norbert
Re: [Pharo-project] I hate 'as yet unclassified'
Am 29.01.2013 um 16:57 schrieb Stéphane Ducasse : > Hi guys > > I spend my time recategorizing methods. > > I would like the change the intention of 'as yet unclassified' because this > is a PLAGUE. > It is like throwing papers on the floor. > So we should have a different name to indicate that it should be fixed. > > > Any ideas? > > 'you are a dirty programmer - change me' > To be honest I have problems understanding why method categorization is so important. Often I don't care a single bit about categories because I don't understand them. I often categorize just to make lint happy :) What is the use? Declaring usage patterns? Declaring visibility? Use as method extensions marker? anything you like just classify? I can understand that it can help making the access of certain methods of a class easier. But that is particular true for classes with a lot of methods. Most of the classes are rather small. In most of my own developments I would consider most huge classes a design problem in my code. So I would try to fix that. And finally it is not easy to learn about them because the browser is not helping. If you browse through the methods of a class the category pane doesn't get updated. So even if I want to learn by getting used to them it is hard. I would make the none categorized term weaker by naming it "uncategorizied" so at least I have the change to deliberately not categorizing my methods without being annoyed by someones opinion about what is essential. my 2 cents, Norbert
[Pharo-project] How to load PetitParser UI in 1.4?
I tried to load version 1.5 of petit parser into a 1.4 image. And I get the error while Glamour is loading announcer already defined in MorphTreeModel Fixing it in the debugger and continue didn't help. I get an exception on opening the petit gui then. Any hints?
Re: [Pharo-project] Smalltalkhub project deletion
Am 15.01.2013 um 21:42 schrieb Igor Stasenko : > On 15 January 2013 15:43, Nicolas Petton wrote: >> I won't mess with the prod db, but thanks anyway ;) >> > you should reconsider. Messing with prod db is one of the most funnier things > :) > Unless have to maintain it :) Norbert > >> Camillo Bruni writes: >> >>> BTW you can mess with the 'p' repository, I created a new 'p4' where I copy >>> all the files for now :) >>> >>> >>> On 2013-01-15, at 15:37, Nicolas Petton wrote: >>> Nope, this is not supposed to work this way :) I'll see what's wrong. Nico Camillo Bruni writes: > I just tried to delete my project to wipe out all versions, but it looks > like > that the versions all re-appear after you create a new project with the > same name > as the old one. > > Is that on purpose? > > best > cami -- Nicolas Petton http://nicolas-petton.fr >>> >>> >> >> -- >> Nicolas Petton >> http://nicolas-petton.fr >> > > > > -- > Best regards, > Igor Stasenko. >
Re: [Pharo-project] Class initialisation after loading
Am 14.01.2013 um 09:24 schrieb Sven Van Caekenberghe : > > On 14 Jan 2013, at 09:09, Norbert Hartl wrote: > >> Am 14.01.2013 um 07:54 schrieb Sven Van Caekenberghe : >> >>> Morning, Norbert, >>> >>> On 14 Jan 2013, at 07:44, Norbert Hartl wrote: >>> >>>> As for every other objects initialize is called when the object is >>>> created. Upgrading code might change the shape of the object but then >>>> there is no initialize call. Do you want to have initialize called every >>>> tiny code change? >>>> Using *cello you can use postLoadDoits to tweak stuff. >>> >>> You mean that, in your opinion, making sure that the #initialize is called >>> in every scenario (new/existing class) can only be done with an explicit >>> action ? >> >> I think that the primary purpose is to initialize newly created space. In >> case of shape change this doesn't happen. So taking the example you >> initialize e.g. an instvar with a collection. Do you want to reinitialize it >> even if you corrected a typo in the comment of a method? >> If I wanted to have control over those things I would on class >> initialization register a class of mine to the local change notification >> system in the image. But this isn't easy to do in a cross platform manner. >> Maybe there are better ways. I'm sure someone will speak up then. > > Let's make it more concrete. Zinc-Resource-Meta-Core is a package that among > other thins contains ZnMimeType. ZnMimeType class>>initialize sets up some > constants (lists of known mime types, file extension to mime type mappings, > you get the idea). When I add new constants in a new source version, I want > them to be added when doing an automated CI build, obviously. Right now, this > does *not* happen, probably because the class and #initialize method already > exist in the image where it is being load in. I understand. The problem is introduced by having a cache of those mime types. That is often a problem because the cache is designed as infinite valid but there is a use case that needs a little less infinite :) I think it depends how often that "adding" takes place. And it seems to me it does not occur very often. Apart from that cache invalidation is one of the more unpleasant things we face. If you want your cache to update you need to check something. But that is what you want to avoid for performance reasons. So I would see a postLoadIt for these rare jobs is a good match. Norbert > Indeed, you would not always want costly initializations to run, but there > should at least be a hook to do it, no ? > >>>> Am 14.01.2013 um 07:20 schrieb Sven Van Caekenberghe : >>>> >>>>> Hi, >>>>> >>>>> For a long time I have been having troubles with #initialize (not) being >>>>> sent to classes that just got loaded. >>>>> >>>>> Apparently #initialize is only sent to *newly* loaded classes that did >>>>> not exist before ? >>>>> >>>>> It does not get sent to existing classes being reloaded/overwritten ? >>>>> >>>>> Does the fact that the #initialize class method itself gets overwritten >>>>> (actually changes) have anything to do with it ? >>>>> >>>>> What would be the best practice here ? The most portable one ? >>>>> >>>>> I want to be able to make sure #initialize is sent when I want it. >>>>> >>>>> Thx, >>>>> >>>>> Sven >>>>> >>>>> PS: I am looking for a solution that would work for Monticello package >>>>> loading, via Gofer or Metacello as well as regular #fileIn. >>>>> >>>>> -- >>>>> Sven Van Caekenberghe >>>>> http://stfx.eu >>>>> Smalltalk is the Red Pill >>> >>> >> > >
Re: [Pharo-project] Class initialisation after loading
Am 14.01.2013 um 07:54 schrieb Sven Van Caekenberghe : > Morning, Norbert, > > On 14 Jan 2013, at 07:44, Norbert Hartl wrote: > >> As for every other objects initialize is called when the object is created. >> Upgrading code might change the shape of the object but then there is no >> initialize call. Do you want to have initialize called every tiny code >> change? >> Using *cello you can use postLoadDoits to tweak stuff. > > You mean that, in your opinion, making sure that the #initialize is called in > every scenario (new/existing class) can only be done with an explicit action ? I think that the primary purpose is to initialize newly created space. In case of shape change this doesn't happen. So taking the example you initialize e.g. an instvar with a collection. Do you want to reinitialize it even if you corrected a typo in the comment of a method? If I wanted to have control over those things I would on class initialization register a class of mine to the local change notification system in the image. But this isn't easy to do in a cross platform manner. Maybe there are better ways. I'm sure someone will speak up then. Norbert > Sven > >> Norbert >> >> Am 14.01.2013 um 07:20 schrieb Sven Van Caekenberghe : >> >>> Hi, >>> >>> For a long time I have been having troubles with #initialize (not) being >>> sent to classes that just got loaded. >>> >>> Apparently #initialize is only sent to *newly* loaded classes that did not >>> exist before ? >>> >>> It does not get sent to existing classes being reloaded/overwritten ? >>> >>> Does the fact that the #initialize class method itself gets overwritten >>> (actually changes) have anything to do with it ? >>> >>> What would be the best practice here ? The most portable one ? >>> >>> I want to be able to make sure #initialize is sent when I want it. >>> >>> Thx, >>> >>> Sven >>> >>> PS: I am looking for a solution that would work for Monticello package >>> loading, via Gofer or Metacello as well as regular #fileIn. >>> >>> -- >>> Sven Van Caekenberghe >>> http://stfx.eu >>> Smalltalk is the Red Pill > >
Re: [Pharo-project] Class initialisation after loading
As for every other objects initialize is called when the object is created. Upgrading code might change the shape of the object but then there is no initialize call. Do you want to have initialize called every tiny code change? Using *cello you can use postLoadDoits to tweak stuff. Norbert Am 14.01.2013 um 07:20 schrieb Sven Van Caekenberghe : > Hi, > > For a long time I have been having troubles with #initialize (not) being sent > to classes that just got loaded. > > Apparently #initialize is only sent to *newly* loaded classes that did not > exist before ? > > It does not get sent to existing classes being reloaded/overwritten ? > > Does the fact that the #initialize class method itself gets overwritten > (actually changes) have anything to do with it ? > > What would be the best practice here ? The most portable one ? > > I want to be able to make sure #initialize is sent when I want it. > > Thx, > > Sven > > PS: I am looking for a solution that would work for Monticello package > loading, via Gofer or Metacello as well as regular #fileIn. > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >
Re: [Pharo-project] SmalltalkHub upgrade
Nico, that's a big leap for smalltalk. Well done! Makes us look more modern now :) Am 11.01.2013 um 18:57 schrieb Nicolas Petton : > Guys, > > SmalltalkHub just got upgraded to version 0.9. This version includes a > lot of changes under the hood, as well as new features and bug fixes: > > New major features: > > - You can now register teams (see the RMoD team > http://smalltalkhub.com/#!/~RMoD) > - Projects can now be private > - The homepage and header have been updated > - SmalltalkHub now includes an (unfinished) "explore" page > (http://smalltalkhub.com/#!/explore) > - and... SmalltalkHub has a new 404 page :-) > (http://smalltalkhub.com/#!/~foo/bar) > Cool page. But I also like the design of http://smalltalkhub.com/foo/bar pages ;) > Updates: > > - Mongo has been updated to version 2.0 > - The production image is a Pharo 1.4 > > Important bug fixes: > > - "disappearing" projects from user dashboard > - mcz files larger than 6Mb could not be uploaded > Norbert
Re: [Pharo-project] Zinc-WebSockets Live Demo
Am 10.01.2013 um 10:02 schrieb Sven Van Caekenberghe : > > On 09 Jan 2013, at 19:31, Norbert Hartl wrote: > >> Am 09.01.2013 um 16:11 schrieb Sven Van Caekenberghe : >> >>> Norbert, >>> >>> On 09 Jan 2013, at 14:57, Norbert Hartl wrote: >>> >>>> Am 09.01.2013 um 14:30 schrieb Sven Van Caekenberghe : >>>> >>>>> Since most proxies and load balancers, most notably Apache, don't handle >>>>> the WebSocket protocol very well, the only solution is to arrange for >>>>> direct connections to the Smalltalk image. >>>> >>>> Who's interested in load balancing for websockets should look at HAProxy >>>> (http://haproxy.1wt.eu/) >>>> >>>> FYI, >>>> >>>> Norbert >>> >>> Yeah, I knew that HAProxy seems to be able to do it, but I didn't want to >>> learn how to deal with the complexity of yet another technology stack. >>> There is also the fundamental question whether it makes sense to >>> proxy/tunnel the semi-permanent WebSocket connections. You would consume >>> twice the resources while gaining little. >>> >> Agreed about yet another stack. But I don't think there is something like a >> fundamental question about those things. In my experience the first or >> second new requirement to your project always proves you wrong :) There are >> often use cases where it is inevitable to have a single entry point, have >> balancing even for TCP connections, pinning, etc… >> >>> Have you used HAProxy ? For WebSockets too ? >> >> I used HAProxy 5 years ago or so. But I'm referring to the experience of a >> friend of mine who actually uses it in production for >> http://www.userlike.de/. He uses Socket.IO for the chat connections and >> there are requirements he needs to use something like HAProxy. > > Cool. So you like HAProxy. Would you say it is easy to use compared to Apache > ? > As I said, my experience with HAProxy is quite dated. It works great but what I remember it was quite hard to convince HAProxy to do what you want to. This situation should (!) have change in the meantime. At least there should be some documentation for certain use cases. HAProxy is widely used in installations so that would be my hope. Apart from that I'm glad my current stuff can be handled by nginx only and I don't have to use any of HAProxy, varnish, etc… These are all good pieces of software with an awful way of configuring it. And you need to know exactly for what purpose they are designed. At the end they are not very flexible that's why you have to find the right software that fits your needs. And when it comes to http every of those solves a distinct 5% of the overall puzzle. > Maybe I do have to try it when I have some time. > IMHO that is always a good idea if you set yourself a limited time frame for it. > If you would recommend it, what would be a good place to start, a good > tutorial ? > I think it's best to wait for my friend to return from vacation (within the next days). I'll bug him them for the information and links and get to you back. >> Btw. my post wasn't meant to "you should use HAProxy". I just wanted to give >> some hints for people who feel they need for it. > > Yes, I understood it that way ;-) > Good :) Norbert
Re: [Pharo-project] Zinc-WebSockets Live Demo
Am 09.01.2013 um 16:11 schrieb Sven Van Caekenberghe : > Norbert, > > On 09 Jan 2013, at 14:57, Norbert Hartl wrote: > >> Am 09.01.2013 um 14:30 schrieb Sven Van Caekenberghe : >> >>> Since most proxies and load balancers, most notably Apache, don't handle >>> the WebSocket protocol very well, the only solution is to arrange for >>> direct connections to the Smalltalk image. >> >> Who's interested in load balancing for websockets should look at HAProxy >> (http://haproxy.1wt.eu/) >> >> FYI, >> >> Norbert > > Yeah, I knew that HAProxy seems to be able to do it, but I didn't want to > learn how to deal with the complexity of yet another technology stack. There > is also the fundamental question whether it makes sense to proxy/tunnel the > semi-permanent WebSocket connections. You would consume twice the resources > while gaining little. > Agreed about yet another stack. But I don't think there is something like a fundamental question about those things. In my experience the first or second new requirement to your project always proves you wrong :) There are often use cases where it is inevitable to have a single entry point, have balancing even for TCP connections, pinning, etc… > Have you used HAProxy ? For WebSockets too ? I used HAProxy 5 years ago or so. But I'm referring to the experience of a friend of mine who actually uses it in production for http://www.userlike.de/. He uses Socket.IO for the chat connections and there are requirements he needs to use something like HAProxy. Btw. my post wasn't meant to "you should use HAProxy". I just wanted to give some hints for people who feel they need for it. Norbert
Re: [Pharo-project] Zinc-WebSockets Live Demo
Am 09.01.2013 um 14:30 schrieb Sven Van Caekenberghe : > Since most proxies and load balancers, most notably Apache, don't handle the > WebSocket protocol very well, the only solution is to arrange for direct > connections to the Smalltalk image. Who's interested in load balancing for websockets should look at HAProxy (http://haproxy.1wt.eu/) FYI, Norbert
Re: [Pharo-project] Persistence Options
Am 17.12.2012 um 19:08 schrieb Torsten Bergmann : > Persisting data is crucial for any application and there > are many ways to do it. Be it RDBMS, NoSQL stuff or in-image > persistency. There are many pre-built solutions: Gemstone, OpenDBX, > SandstoneDB, Mongo, ... > > From time to time I ask the question here on the list > to see how it evolves and what people actually use in > their Pharo applications: > > 1. What persistence option do we currently have I like to add plain fuel. I store e.g. configurations with it as these change rarely. For reliability I applied a sequence file to it. Meaning I write files with .fl.1, .fl.2, etc. and a file seq containing the last written number extension. The mechanic is to first write the fuel file and then overwrite the seq file with the actual sequence number (if a write fails the seq file isn't changed). Reads are reading first the seq file and then the fuel file. > 2. What persistence is used in your Pharo application today GemStone, MongoTalk (maybe soon it will be voyage, too), Fuel, Sixx. And in testing phase riak (no phriak, yet). > 3. Which persistence solution you want to use/would you >like to see in Pharo's future A decent implementation of LOOM. I think as long as there are different types of memory (main memory, disc storage,..) this is something nice to have. > 4. What would you recommend. > Reify object references :) Norbert
Re: [Pharo-project] [Pharo-consortium] VMWare golden pharo consortium :)
Am 11.12.2012 um 10:09 schrieb Stéphane Ducasse : > Hi guys > > we are happy to announce that VMWare is a golden consortium member of the > pharo consortium. > A good member indeed. Thanks to our friends at Ge….VMWare! Norbert
Re: [Pharo-project] [update 2.0] #20430
Am 06.12.2012 um 15:42 schrieb Esteban Lorenzano : > well... I agree with you (that was the icon I was using with the first ones, > in mac), but Stef likes more the other: > > > > > :) > I agree with Steph. That looks better if the icon is displayed tiny e.g. in the finder. And of course… http://cdnimg.visualizeus.com/thumbs/be/14/fun,true,frases,quote,text,circle-be1490d72664b693d134ef0e8449a1b5_h.jpg Norbert > > > On Dec 6, 2012, at 3:39 PM, "Torsten Bergmann" wrote: > >>> I'm working now in produce branded Pharo VMs with NB support out of the >>> box. >> >> Please - can we use the attached icon for the new "branded" >> windows VM. It is more Pharo like than the "Cog wheel" one and >> includes all sizes. >> >> Thanks >> T. >> >
Re: [Pharo-project] Got our first pharo consortium contract :)
Am 27.11.2012 um 11:51 schrieb Sophie Perin : > Dear Norbert > > You can pay now but you pay for 2013 calendar year. > > the pro-rata apply and it is calculated only when a compagny joins the > consortium during the calendar year (for example, if a compagny sign the > membership agreement on june 2013) > > Hope it is clear now for you ? > Yes, thank you. Memberships are adjusted to the calendar year. In this case it is the same for us regardless when we pay (tax wise). So I just wait for you to settle things. thanks again, Norbert > - Mail original - >> De: "Norbert Hartl" >> À: Pharo-project@lists.gforge.inria.fr >> Cc: "Sophie Perin" >> Envoyé: Mardi 27 Novembre 2012 11:42:17 >> Objet: Re: [Pharo-project] Got our first pharo consortium contract :) >> >> >> Am 27.11.2012 um 10:35 schrieb Stéphane Ducasse >> : >> >>> Norbert >>> >>>>> Great!. And being the first is always something special :) Do you >>>>> think the fees can be transferred already this year? >>> >>> We decided to do a pro-rata so that people do not think that we are >>> trying to steal them and also to make sure that >>> everybody can join at any time without thinking too much. >>> So it would mean 1 month so it will be probably for january. Now if >>> you want to pay the full >>> price we can do it :). >>> >> I'm not sure I understand. My assumption was that whenever I join the >> consortium I pay an annual fee and be member for one year. Or do you >> arrange the membership payment with the calendar year? So to be >> clear do you state paying for this year will be one month (for >> december) and it starts all over again in 2013? Or will I be able to >> pay now for one year (until Nov '13)? >> For us it would be best to pay a year of membership within 2012. >> >> Norbert >> >> >>
Re: [Pharo-project] Got our first pharo consortium contract :)
Am 27.11.2012 um 10:35 schrieb Stéphane Ducasse : > Norbert > >>> Great!. And being the first is always something special :) Do you think the >>> fees can be transferred already this year? > > We decided to do a pro-rata so that people do not think that we are trying to > steal them and also to make sure that > everybody can join at any time without thinking too much. > So it would mean 1 month so it will be probably for january. Now if you want > to pay the full > price we can do it :). > I'm not sure I understand. My assumption was that whenever I join the consortium I pay an annual fee and be member for one year. Or do you arrange the membership payment with the calendar year? So to be clear do you state paying for this year will be one month (for december) and it starts all over again in 2013? Or will I be able to pay now for one year (until Nov '13)? For us it would be best to pay a year of membership within 2012. Norbert
Re: [Pharo-project] Got our first pharo consortium contract :)
Am 26.11.2012 um 22:01 schrieb Stéphane Ducasse : > Hi guys > > This is a great day. We got our first pharo consortium contract signed by a > great > company: 2Denker :) > Great!. And being the first is always something special :) Do you think the fees can be transferred already this year? Norbert > Thanks for your trust! > > Soon the web site will get from the ground. > Esteban got distracted by some VM bug chasing parties but he will be back on > it. > > Stef
Re: [Pharo-project] MongoTalk update
Am 24.11.2012 um 14:06 schrieb Nicolas Petton :
>
> Thanks Norbert!
>
> It's cool to know that you like it :) Together with Esteban's work on
> Voyage, it allows us to do extremely cool stuff with Mongo and Pharo.
>
> What I like with Voyage-Mongo + MongoQueries is that objects are
> persisted without any effort, it just works, and we can query Mongo
> collections like we would do with Smalltalk collections.
>
Sure, that sounds cool. I didn't look into the new voyage, yet. But I need to
tell Esteban how cool it is to clear a past misunderstanding :)
Norbert
> Nico
>
> Norbert Hartl writes:
>
>> Hey Nico,
>>
>> I looked into your new stuff and I like it. Especially the MongoQueries
>> stuff is very simple and clean approach to do a small DSL. That boosts the
>> usability of MongoTalk extremely. Bravo!
>>
>> Norbert
>>
>> Am 19.11.2012 um 15:37 schrieb Nicolas Petton :
>>
>>>
>>> Hi guys,
>>>
>>> Lately I worked a bit on the Pharo Mongo driver for SmalltalkHub. I made
>>> several changes (in the new version 1.4):
>>>
>>> The query API changed:
>>>
>>> - MongoCollection>>query: now takes a 1 arg block, improving the API
>>> quite a bit.
>>>
>>> Queries like:
>>>
>>> aCollection query: (aCollection query
>>> query: { 'foo' -> 'bar'} asDictionary;
>>> yourself)
>>>
>>> Is now written:
>>>
>>> aCollection query: [ :query |
>>> query where: { 'foo' -> 'bar'} ]
>>>
>>> Sending #asDictionary has also been made optional, the query builder
>>> will send #asMongoQuery to the query collection.
>>>
>>>
>>> The MongoQueries package:
>>>
>>> Version 1.4 comes with a new package MongoQueries, a small DSL allowing
>>> us to use traditional blocks instead of dictionaries to perform
>>> queries. This is optional and backward compatible.
>>>
>>> Queries like:
>>>
>>> aCollection select: { '$or' -> { 'name' -> 'foo'. 'age' -> { '$gt' -> 23 }
>>> asDictionary } asDictionary } asDictionary
>>>
>>> can be expressed:
>>>
>>> aCollection select: [ :each | (each name = 'foo') | (each age > 23) ]
>>>
>>> The MongoQueries package should support the entire mongo query language
>>> (including nested queries), and comes with unit tests.
>>>
>>> Nico
>
> --
> Nicolas Petton
> http://nicolas-petton.fr
Re: [Pharo-project] smalltalkhub and project ownership
Am 22.11.2012 um 13:47 schrieb Sebastian Sastre : >> Is there an explanation why in smalltalkhub every project resides below a >> user? > > > because things in this universe don't get done if someone isn't leading it? :D > > the leader of any project is (a) the curator of that project and (b) the one > positioned to better inspire followers > > if people likes it, people follows the project and/or the guy > > if someone doesn't like the direction, that person can fork and lead it > himself in another direction > > github got it right, I'm glad smalltalkhub too > > and it's not about mimicking github (which wouldn't be bad) it's mimicking > the way people want to work > > it's about natural selection applied to software projects at its best > > makes sense? partially. Don't want to extend it here! > > PD: if someone abandons a project, no big deal, it will be there hanging out > while another fork might be flourishing. Also projects property should be > transferrable from one user to another for the cases in which that happens > orderly. > > Yep, that is my point. I didn't want to argue against anything smalltalkhub does. Regardless if you mimick github or "the way people want to work[™]" you need to have basic functionality. In github forks are connected so I always see where a thing comes from. By just copying stuff we will produce a mess. Someone that encounters smalltalkhub will then see 5 slightly different copies of the same thing and he couldn't estimate which one is the one to go first. So my question was if there is an idea how to solve this in smalltalkhub. No matter if it exists already or is being planned. Norbert
[Pharo-project] smalltalkhub and project ownership
Is there an explanation why in smalltalkhub every project resides below a user? I just saw that Francois moved the MongoTalk from squeaksource to smalltalkhub. With the move the project moved into francois' projects. That seems like a step back at first. In squeaksource projects are global and have certain roles attached. Thus making it easier to shift responsibility. Especially when a user takes over a project and then stops working on it what would be the workflow for this? Can projects be moved? Do we need to copy? I can see that there is a tension to mimick github. But in github I just fork a project under my own account where it can reside even if the original author abandoned the project. What would be a good way to handle that common use case? thanks, Norbert
Re: [Pharo-project] MongoTalk update
Hey Nico,
I looked into your new stuff and I like it. Especially the MongoQueries stuff
is very simple and clean approach to do a small DSL. That boosts the usability
of MongoTalk extremely. Bravo!
Norbert
Am 19.11.2012 um 15:37 schrieb Nicolas Petton :
>
> Hi guys,
>
> Lately I worked a bit on the Pharo Mongo driver for SmalltalkHub. I made
> several changes (in the new version 1.4):
>
> The query API changed:
>
> - MongoCollection>>query: now takes a 1 arg block, improving the API
> quite a bit.
>
> Queries like:
>
> aCollection query: (aCollection query
>query: { 'foo' -> 'bar'} asDictionary;
>yourself)
>
> Is now written:
>
> aCollection query: [ :query |
>query where: { 'foo' -> 'bar'} ]
>
> Sending #asDictionary has also been made optional, the query builder
> will send #asMongoQuery to the query collection.
>
>
> The MongoQueries package:
>
> Version 1.4 comes with a new package MongoQueries, a small DSL allowing
> us to use traditional blocks instead of dictionaries to perform
> queries. This is optional and backward compatible.
>
> Queries like:
>
> aCollection select: { '$or' -> { 'name' -> 'foo'. 'age' -> { '$gt' -> 23 }
> asDictionary } asDictionary } asDictionary
>
> can be expressed:
>
> aCollection select: [ :each | (each name = 'foo') | (each age > 23) ]
>
> The MongoQueries package should support the entire mongo query language
> (including nested queries), and comes with unit tests.
>
> Nico
>
Re: [Pharo-project] [Pharo-consortium] Pharo consortium agreement
So, what's best. Wait to finalize the form or print and send? Norbert Am 06.11.2012 um 17:24 schrieb Stéphane Ducasse : > Dear Pharoers > > Here is the result of the work we did around the consortium for Pharo for > about 2 years. We took into account all your remarks over the years > and we think that the result is good and corresponds to what the community > can support. > This consortium is important for Pharo's future and it will help us to > deliver a system to help you making business. > Our goal is to be able to collect fundings to pay at least one full time > engineer. > > The idea is that all the consortium members will sign the same agreement. We > will not handle modifications per partners. > Now since we are starting the process if you spot some glitches on the form > let us know. We can discuss and fully stabilize one version. > > We suggest to read the document. > - If you agree to sign it and send it to us (in two copies if you do it > by surface mail at > INRIA - S. Ducasse - Pharo, 40, avenue Halley, Parc > Scientifique de la Haute Borne, > Bât.A, Park Plaza, Villeneuve d'Ascq, FR-59650, > France.), so that we sign it too. > - Don't forget to complete your legal mention on first page and your > contact details on article 14 before signing. :) > > We will launch soon two web sites: > - one for the Pharo user association and > - one for the Pharo consortium. > > > A side note: we will communicate about it later and separately but Inria > decided to support the consortium by paying one extra year to Igor Stasenko. > This is around 60 Keuros in addition to the year of Esteban Lorenzano and > previous years of Igor. > > I really want to thank Inria for the constant support and the work of S. > Karpf, P. Moreau and S. Perin. > > Stef > > <2012-11-06-consortium PHARO.pdf> > > > > > > Dr. Stéphane Ducasse -- Directeur de Recherche (Senior Researcher) > INRIA - USTL - CNRS UMR 8022 > stephane.duca...@inria.fr > http://stephane.ducasse.free.fr > http://rmod.lille.inria.fr/ > **NEW ***Tel 00 33 (0)3 59 35 87 52 - Fax 33 3 59 57 78 50 > > 40, avenue Halley, Parc Scientifique de la Haute Borne, > Bât.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France. > > > > > > > > ___ > Pharo-consortium mailing list > pharo-consort...@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-consortium
Re: [Pharo-project] SSL Failing on Mac
Am 25.10.2012 um 07:42 schrieb Sven Van Caekenberghe : > Igor, Sean, > > On 25 Oct 2012, at 04:19, Igor Stasenko wrote: > >> I have some: >> - add tests to check if it works. So we will know if it functional or not >> before people >> will start using it and find by themselves :) > > I know that an older plug works, that is not the problem. > > Also, the tests are there: jenkins is building with all Zodiac tests passing. > > The questions are: > > - are we talking about the same vm ? > - if so, why does it work on the build server and not for users ? > I partially answered that in a response to another mail of you. If it comes to dynamic libs there is a source for failure. The library setup is not the same for every e.g. linux. So the prerequisites are compiled into the library but there is nothing to check at installation time. The vm is distributed in a plain file archive and not in an installation package. Building package for each platform could solve it :) I'm thinking since a longer time to package the vm for me so my deployment time will be reduced. It isn't very hard to build those packages. Norbert
Re: [Pharo-project] Confused about SSL Plugin dependencies
Am 24.10.2012 um 22:08 schrieb Sven Van Caekenberghe : > Assuming > > http://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/Architecture=32,OS=linux/lastSuccessfulBuild/artifact/Cog-linux.zip > > as linked from > > http://www.pharo-project.org/pharo-download > > is the official Linux VM used by the whole build process, I am confused about > the dependencies of the shipped SSL plugin. > > On my Ubuntu machine, the following output is of the working plugin: > > ubuntu@ip-10-48-234-254:~/experimental$ ldd bin/libSqueakSSL.so > linux-gate.so.1 => (0xb7702000) > libm.so.6 => /lib/i386-linux-gnu/tls/i686/nosegneg/libm.so.6 > (0xb76c6000) > libdl.so.2 => /lib/i386-linux-gnu/tls/i686/nosegneg/libdl.so.2 > (0xb76c1000) > libpthread.so.0 => > /lib/i386-linux-gnu/tls/i686/nosegneg/libpthread.so.0 (0xb76a6000) > libssl.so.0.9.8 => /lib/i386-linux-gnu/libssl.so.0.9.8 (0xb7657000) > libc.so.6 => /lib/i386-linux-gnu/tls/i686/nosegneg/libc.so.6 > (0xb74ad000) > /lib/ld-linux.so.2 (0xb7703000) > libcrypto.so.0.9.8 => /lib/i386-linux-gnu/libcrypto.so.0.9.8 > (0xb7334000) > libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb731e000) > > While the following output is of the non-working version downloaded from the > links above > > ubuntu@ip-10-48-234-254:~/experimental$ ldd pharocog/libSqueakSSL.so > linux-gate.so.1 => (0xb77a7000) > libssl.so.6 => not found > libc.so.6 => /lib/i386-linux-gnu/tls/i686/nosegneg/libc.so.6 > (0xb75ee000) > /lib/ld-linux.so.2 (0xb77a8000) > > What package has to be installed to resolve this dependency ? > Against which library was this variant of the SSL plugin built ? > For me 0.9.8 of the library works. There is just mismatch in the library name SSL is linked and what you get installed in a fresh ubuntu. If you look here # ls -l /usr/lib/i386-linux-gnu/libssl* -rw-r--r-- 1 root root 240624 Aug 16 17:54 /usr/lib/i386-linux-gnu/libssl3.so lrwxrwxrwx 1 root root 35 Apr 24 2012 /usr/lib/i386-linux-gnu/libssl.so.0.9.8 -> /lib/i386-linux-gnu/libssl.so.0.9.8 we have a libssl.so.0.9.8. But the plugin is linked to a library libssl.so.6. To fix this execute # ln -s /usr/lib/i386-linux-gnu/libssl.so.0.9.8 /usr/lib/i386-linux-gnu/libssl.so.6 Maybe you need to invoke ldconfig afterwards. Norbert > I alread have both the following > > ubuntu@ip-10-48-234-254:~/experimental$ aptitude search "~i" | grep ssl > i A libio-socket-ssl-perl - Perl module implementing object > oriented i > i A libnet-ssleay-perl - Perl module for Secure Sockets Layer > (SSL) > i libssl0.9.8 - SSL shared libraries > > i A libssl1.0.0 - SSL shared libraries > > i openssl - Secure Socket Layer (SSL) binary and > relat > i python-openssl - Python wrapper around the OpenSSL > library > i A ssl-cert- simple debconf wrapper for OpenSSL > > > Thx, > > Sven > > > >
[Pharo-project] RFB on pharo 2.0
Does anyone have a working RFB version for pharo 2.0? Norbert
Re: [Pharo-project] CogVM segfault
Strange! I had command line switches -nodisplay -nosound -memory 512m If I take away the memory switch then it works. Norbert Am 18.10.2012 um 13:36 schrieb Norbert Hartl : > Uhm, forgot. I tried this on linux ubuntu 12.04 64 bit with ia32-libs. > > Norbert > > Am 18.10.2012 um 13:34 schrieb Norbert Hartl : > >> I want to start using 2.0 for my projects. So I created a jenkins job to >> build images. But I can't. The vm segfaults immediately. I downloaded the >> CogVM from the pharo-project.org site. After failing I got myself one from >> the CI server with the same result. The image was taken from the >> pharo-project.org site. >> >> I attach the crash dump. Hope you can find something. The last line involves >> (DiskStore) where it collapsed. It seems like a problem in the file handling >> code. But then it also seems that it was trying to open the sources file. Is >> there a special location where it looks after it? I places it in the >> directory where the image resides an also in the vm directory. >> >> Norbert >> >> > >
Re: [Pharo-project] CogVM segfault
Uhm, forgot. I tried this on linux ubuntu 12.04 64 bit with ia32-libs. Norbert Am 18.10.2012 um 13:34 schrieb Norbert Hartl : > I want to start using 2.0 for my projects. So I created a jenkins job to > build images. But I can't. The vm segfaults immediately. I downloaded the > CogVM from the pharo-project.org site. After failing I got myself one from > the CI server with the same result. The image was taken from the > pharo-project.org site. > > I attach the crash dump. Hope you can find something. The last line involves > (DiskStore) where it collapsed. It seems like a problem in the file handling > code. But then it also seems that it was trying to open the sources file. Is > there a special location where it looks after it? I places it in the > directory where the image resides an also in the vm directory. > > Norbert > >
[Pharo-project] CogVM segfault
I want to start using 2.0 for my projects. So I created a jenkins job to build images. But I can't. The vm segfaults immediately. I downloaded the CogVM from the pharo-project.org site. After failing I got myself one from the CI server with the same result. The image was taken from the pharo-project.org site. I attach the crash dump. Hope you can find something. The last line involves (DiskStore) where it collapsed. It seems like a problem in the file handling code. But then it also seems that it was trying to open the sources file. Is there a special location where it looks after it? I places it in the directory where the image resides an also in the vm directory. Norbert crash.dmp Description: Binary data
Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree
Am 01.10.2012 um 21:29 schrieb Stéphane Ducasse : > Don't say that camillo because this is the ultimate argument against > communication. > Uh? Come on, Steph. That is something you can read frequently on the mailing list. This times just the roles have switched. So please be fair. Norbert > > On Oct 1, 2012, at 8:44 PM, Camillo Bruni wrote: > >> how much did you contribute to this project igor? >> >> It's open-source, so stop complaning, start implementing! >> >> On 2012-10-01, at 20:42, Igor Stasenko wrote: >> >>> oh, and i forgot the most important thing: >>> >>> classes should also have a stamp, i.e. author and date (and perhaps mood ;). >>> Because it feels strange to me, that each method has stamp, even class >>> comments has stamp, >>> but not the classes. >>> What if my sole change is adding/removing variable(s) or changing a >>> superclass? >>> This information (like who and when did that) is also very useful in >>> same way as for methods. >>> >>> Yes, i know that Squeak/Pharo does not support that, not sure about >>> other dialects. But we can do better isn't? >> > >
Re: [Pharo-project] ohloh is sad
Am 03.07.2012 um 21:29 schrieb Camillo Bruni: > we have only 8 users on ohloh :P > > https://www.ohloh.net/p/pharo/users > > now I want to see everybody from the mailinglist on there :P > Yet another community? why? To me it appears the main asset is that it checks contributions which it can't do in our environment. What is it good for? thanks, Norbert
