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

Re: [Pharo-users] Voyage and instances retrieving

by Hilaire

I'll make a test case to illustrate the issue. Hilaire Le 06/03/2017 Ã 19:05, Esteban Lorenzano a Ã©crit : >> Ah, sorry I was not clear enough in my introduction. Obviously, I >> removed all =/hash overrides on the involved objects and it is therefore >> an orthogonal issue (that's why I first resolved the other issues >> first). Or did you mean something I did not understand in your previous >> message? > no, I didnât understood you removed #= and #hash :) > -- Dr. Geo http://drgeo.eu

March 7, 2017

Re: [Pharo-users] Pharo Spur 64 VM

by Raffaello Giulietti

My guess is, yes, while 90% of the desktops still run Windows, probably most of the developers related to Pharo use macOS. And since macOS is similar to Linux, porting to Linux is easy while porting to Windows seems not for the reasons outlined by ClÃ©ment. On 2017-03-07 04:58, HernÃ¡n Morales Durand wrote: > Just asking, > > Did someone already tried to get funding to update the Windows VM? > Because it's like the 90% of the world still uses Windows... > > Regards, > > HernÃ¡n > > > > 2017-03-02 12:51 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com > <mailto:bera.clement@gmail.com>>: > > Hi Raffaello, > > Reportedly, the VM without the JIT (pure interpreter, also called > PharoS or StackVM) works on windows 64 and FFI works with it if > the VM compiled with clang but not with gcc. There is no > configuration for Pharo right now. It should not be hard to add a > pharo configuration to have the image start-up, but I don't think > several libraries such as Athens/Cairo or libgit would work out of > the box, so it's not clear such a configuration would make a lot > of sense. There is no PharoS-spur64 repository on files.pharo.org > <http://files.pharo.org> right now either. > > Windows support is not ready mostly because: > - Some C types are different in x64 between Unix and windows > - Calling conventions are different in x64 bits between Unix and > Windows > > Calling conventions have impact in switching between the > interpreter and the JIT runtime and in FFI. > C types being different have impact for the VM compilation and in FFI. > > If someone looks into it, I guess in a day of work we could have > the Stack VM working with Spur 64 for Pharo without support for > some librairies. There might be uncommon crashes to fix over the > first week of use. With several more weeks of work (maybe a couple > months), the StackVM with all libraries should be > production-ready. The JIT support will take more time, hopefully > it will be done in a year from now. > > Maybe I should mention that the company who funded 64 bits support > is using the VM on Mac for development and Linux for production, > so Windows was not a priority and not done. We have to rely on > open-source contributors, non paid, to add Windows support and > that takes time. Nicolas Cellier added the support for the 64 bits > Stack VM on his free time. If someone is investing money, the 64 > bits Windows VM could reach production sooner (I guess within 6 > months) because someone could work full time on it. > > Regards, > > On Thu, Mar 2, 2017 at 4:04 PM, <raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>> wrote: > > On 07/02/17 07:13, Esteban Lorenzano wrote: > > > >> On 6 Feb 2017, at 21:41, Cyril Ferlicot D. > <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>> > wrote: > >> > >> Le 06/02/2017 Ã 21:31, Benoit St-Jean via Pharo-users a Ã©crit : > >> > >> > >> Hi! > >> > >> IIRC, the windows VM will need some more time to be ready. > Only Linux > >> and OSX ones are usable at the moment. > > > > ^ this. > > as Cyril says, win 64bits vm is still not ready (and it will > take some more time to be). > > > > Esteban > > > > > Just for general curiosity, what are the main stumbling blocks > in the > road to a Windows 64 bit Pharo? > > > Raffaello > > > >

March 7, 2017

Re: [Pharo-users] Seaside : including a static stylesheet.

by Sabine Manaa

Hi Dominique, for some cases I also use static files on my local machine, the root directory of the local machines web server is /Library/WebServer/Documents perhaps this is what you are looking for. regards Sabine 2017-02-28 18:53 GMT+01:00 Dominique Dartois <dom(a)dartois.org>: > In the Seaside book, chapter 17.2 I read I can include a stylesheet this > way : > > updateRoot: anHtmlRoot > super updateRoot: anHtmlRoot. > anHtmlRoot stylesheet url: 'http://seaside.st/styles/main.css' > > On my development machine (macOS) I use http://localhost:8080/myApp as > the server address and I donât know the root directory of the Seaside > integrated web server. > > Can anyone help me to find this directory? > > Thanks. > > > > --- > > Dominique Dartois >

March 7, 2017

Re: [Pharo-users] Pharo Association

by denker

> On 1 Mar 2017, at 18:29, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > Hello, I am looking into the Pharo Association. > > I looked at the Contribute page, http://pharo.org/contribute and saw the links to BountySource. > > One of them had $9 monthly being a Gold Membership Pharo Association. I do not see this as an option if you do Join on the Pharo Association Join Us page, https://association.pharo.org/join-us . > Yes. Integrating salt there would be very complex. For one, we do not get any email/information from Salt about new members. So this is manual: it is one form of payment. (like money transfer). > I do not know which option is most favorable for or least expensive to the Pharo Association. > Direct membership. Bountisource costs 10%. > I also do not see what payment methods are available on the Pharo Association pages. BountySource I know my options. > > From the BountySource page I do not know how this connects me to the PharoAssociation. > Not directly as they do not tell us when a new person subscribes. > If all things are equal, I would assume do BountySource, I can start a monthly cash flow immediately. > > It would also be nice to know if doing BountySource that is always an option to levels other than the set levels but you only get the benefits of the highest level you contribute at. > > For example if I wanted to do $15 a month instead of $9, or even a simply $10 instead of $9. or â¦. Sadly we can not change the despriptions at SALT. I did send a mail to support but never got an answer. > I think this could be by instead of saying $9 a month, express it as minimum of $9 a month. Or what is appropriate for each level. > > If BountySource is more expensive on the Association's end. I would prefer to do whatever payment options are on the Association site. But it would be nice to know what those are before I begin to complete the forms. > Best is to go directly via the association. Espeically that Salt - does not tell us new sponsors - does not respond to suport requests - takes 10% for that Marcus

March 7, 2017

Re: [Pharo-users] [State Machine] Looking for some examples.

by HernÃ¡n Morales Durand

I never used StateMachine, but a really cool package with some examples is SState: http://www.smalltalkhub.com/#!/~MasashiUmezawa/SState Cheers, HernÃ¡n 2017-03-07 1:14 GMT-03:00 sergio ruiz <sergio.rrd(a)gmail.com>: > Hey, all.. > > Just wondering if anyone had any resources for examples of using > StateMachine package in Pharo. > > I am looking at it, and looked at the tests, but am not finding a really > clear example on how this works. > > Ideas? > > Thanks! > > > ---- > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.Village-Buzz.com > http://www.ThoseOptimizeGuys.com > http://www.coffee-black.com > http://www.painlessfrugality.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 >

March 7, 2017

couchdb integration?

by Tudor Girba

Hi, Does anyone know if there any CouchDB integration in Pharo? For example, I would be interested if there is any Pharo implementation for the CouchDB Replication Protocol: http://docs.couchdb.org/en/master/replication/protocol.html Cheers, Doru -- www.tudorgirba.com www.feenk.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

March 7, 2017

[State Machine] Looking for some examples.

by sergio ruiz

Hey, all.. Just wondering if anyone had any resources for examples of using StateMachine package in Pharo.Â I am looking at it, and looked at the tests, but am not finding a really clear example on how this works. Ideas? Thanks! ---- peace, sergio photographer, journalist, visionary Public Key:Â http://bit.ly/29z9fG0 #BitMessageÂ BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.Village-Buzz.com http://www.ThoseOptimizeGuys.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

March 7, 2017

Re: [Pharo-users] Pharo Spur 64 VM

by HernÃ¡n Morales Durand

Just asking, Did someone already tried to get funding to update the Windows VM? Because it's like the 90% of the world still uses Windows... Regards, HernÃ¡n 2017-03-02 12:51 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Hi Raffaello, > > Reportedly, the VM without the JIT (pure interpreter, also called PharoS > or StackVM) works on windows 64 and FFI works with it if the VM compiled > with clang but not with gcc. There is no configuration for Pharo right now. > It should not be hard to add a pharo configuration to have the image > start-up, but I don't think several libraries such as Athens/Cairo or > libgit would work out of the box, so it's not clear such a configuration > would make a lot of sense. There is no PharoS-spur64 repository on > files.pharo.org right now either. > > Windows support is not ready mostly because: > - Some C types are different in x64 between Unix and windows > - Calling conventions are different in x64 bits between Unix and Windows > > Calling conventions have impact in switching between the interpreter and > the JIT runtime and in FFI. > C types being different have impact for the VM compilation and in FFI. > > If someone looks into it, I guess in a day of work we could have the Stack > VM working with Spur 64 for Pharo without support for some librairies. > There might be uncommon crashes to fix over the first week of use. With > several more weeks of work (maybe a couple months), the StackVM with all > libraries should be production-ready. The JIT support will take more time, > hopefully it will be done in a year from now. > > Maybe I should mention that the company who funded 64 bits support is > using the VM on Mac for development and Linux for production, so Windows > was not a priority and not done. We have to rely on open-source > contributors, non paid, to add Windows support and that takes time. Nicolas > Cellier added the support for the 64 bits Stack VM on his free time. If > someone is investing money, the 64 bits Windows VM could reach production > sooner (I guess within 6 months) because someone could work full time on it. > > Regards, > > > On Thu, Mar 2, 2017 at 4:04 PM, <raffaello.giulietti(a)lifeware.ch> wrote: > >> On 07/02/17 07:13, Esteban Lorenzano wrote: >> > >> >> On 6 Feb 2017, at 21:41, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> >> wrote: >> >> >> >> Le 06/02/2017 Ã 21:31, Benoit St-Jean via Pharo-users a Ã©crit : >> >> >> >> >> >> Hi! >> >> >> >> IIRC, the windows VM will need some more time to be ready. Only Linux >> >> and OSX ones are usable at the moment. >> > >> > ^ this. >> > as Cyril says, win 64bits vm is still not ready (and it will take some >> more time to be). >> > >> > Esteban >> > >> >> >> Just for general curiosity, what are the main stumbling blocks in the >> road to a Windows 64 bit Pharo? >> >> >> Raffaello >> >> >> >

March 7, 2017

Re: [Pharo-users] MOOC english subtitles

by Offray Vladimir Luna CÃ¡rdenas

Hi, On video translations for the MOOC (and other videos) I would recommend Amara[1]. It enables collaborative translations and their web interface is pretty friendly. In the mock up I made on [2], you can see how the Amara embedded player enables subtitles for one of the MOOC videos, that is one of the first I would like to translate to Spanish (hopefully when I finish my thesis). [1] http://amara.org/ [2] http://mutabit.com/repos.fossil/alvicoda/doc/tip/index.html Cheers, Offray On 06/03/17 15:37, stepharong wrote: > > >> May I do a pass over the english subtitles for the MOOC? >> With the limited space and reading time you get with subtitles, >> I see some things I could fine-tune. > > Of course. > A company did them and we were really happy because french :) > Now I wonder how we can make sure that we keep the modified file > clearly distinguishable > from the old one. > I suggest that you copy the file and add a -v2.srt > > Stef > >> >> One query on content, from [1] it says there are "good comments" >> when I'd guess it would say "poor comments" from there being no class >> comment >> >> 16 >> 00:00:49,830 --> 00:00:51,920 >> The system searches a little >> and says that there are >> 17 >> 00:00:53,200 --> 00:00:56,290 >> good comments. We will see this later. >> For the moment, we donât care. > > probably wrong :) > >> >> cheers -ben >> >> [1] >> https://github.com/SquareBracketAssociates/PharoMooc/blob/master/Subtitles/… >> > >

March 7, 2017

Re: [Pharo-users] why is concat of Symbols a string?

by Ben Coman

Thanks Sven. cheers -ben On Tue, Mar 7, 2017 at 2:43 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Ben, > > I tried to avoid #isString and #isSymbol and I thought it was clear that #assert:equals: used #= but I agree that I could be more explicit. Here is the changed version of the unit test (.2 of slice): > > testConcatenationIsSymbol > "Concatenating 2 symbols results in another symbol" > self assert: (#foo , #bar) isSymbol. > self assert: (#foo , #bar) == #foobar. > > "Concatenating the empty Symbol does not change a Symbol" > self assert: (#foo , emptySymbol) == #foo. > self assert: (emptySymbol , #foo) == #foo. > > "Strings and Symbols can still be mixed, the receiver determines the result type" > "Symbol receiver gives Symbol result" > self assert: (#foo , 'bar') isSymbol. > self assert: (#foo , 'bar') == #foobar. > "String receiver gives String result" > self assert: ('foo' , #bar) isString. > self assert: ('foo' , #bar) = 'foobar'. > "Strings and Symbols still compare content-wise" > self assert: ('foo' , #bar) = #foobar. > "But Strings and Symbols are not identical" > self deny: ('foo' , #bar) == #foobar. > > >> On 6 Mar 2017, at 15:18, Ben Coman <btc(a)openinworld.com> wrote: >> >> On Mon, Mar 6, 2017 at 9:21 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> On 6 Mar 2017, at 14:12, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> >>>> >>>> On Mon, Mar 6, 2017 at 5:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> Here is a concrete proposal: >>>> >>>> https://pharo.fogbugz.com/f/cases/19802/Make-sure-Symbol-concatenation-resu… >>>> >>>> This gives the following assertions: >>>> >>>> "Concatenating 2 symbols results in abother symbol" >>>> self assert: (#foo , #bar) == #foobar. >>>> >>>> "Concatenating the empty symbol does not change a symbol" >>>> self assert: (#foo, emptySymbol) == #foo. >>>> self assert: (emptySymbol, #foo) == #foo. >>>> >>>> "Strings and symbols can still be mixed, the receiver determines the result type" >>>> "Symbol receiver gives symbol result" >>>> self assert: (#foo , 'bar') == #foobar. >>>> "String receiver gives string result" >>>> self deny: ('foo' , #bar) == #foobar. >>>> self assert: ('foo' , #bar) equals: #foobar. >>>> self assert: ('foo' , #bar) equals: 'foobar'. >>>> >>>> >>>> Those last two seem contradictory. >>> >>> No, Symbols and String can be used interchangeably in Pharo in lots of contexts. Particularly when comparing them, it makes no difference, all the following are/have always been true, independent of this change: >>> >>> #foo = 'foo' >>> 'foo' = #foo >>> #foo = #foo >>> 'foo' = 'foo' >> >> Ah-ha... gotchya. always something more to learn. >> >> So those last three lines a testing that it is a String? >> This meaning is pretty well hidden in the implicit behaviour. >> Why not just... >> self assert: (#foo , 'bar') isString >> which seems to better "says what it means" >> >> If such is poor form in general, >> I'm curious to what degree such rules may be relaxed for unit tests. >> Could it be considered something like premature optimisation >> to make the test too generic?? If isString latter causes a problem later, >> deal with it then. >> >> ==== >> On another slightly different point, >> this might be one case where #assert:#equals is less clear than using "=" >> >> Its also easy to mis-think the following is contradictory >>>> self deny: ('foo' , #bar) == #foobar. >>>> self assert: ('foo' , #bar) equals: #foobar. >> >> where the alternative here makes the distinction more clear... >> self deny: ('foo' , #bar) == #foobar. >> self assert: ('foo' , #bar) = #foobar. >> >> >> cheers -ben > >

March 6, 2017