- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] http://pharo.org/files/pharo.png

by stepharo

No idea but it should not because it breaks our nice examples. if you have the file I can add it back. May be esteban when he was removing Amber dependencies in Marina. Stef Le 6/11/16 Ã 18:14, Sven Van Caekenberghe a Ã©crit : > Who removed http://pharo.org/files/pharo.png ? > > Why ? > > It is used in tests/examples. > > Could it be put back please, even it is not used (it does do no harm) ? > > A basic rule of the Web is not to break existing stuff. yes but there is no become/allInstances to find who is using you > > Sven > >

Nov. 6, 2016

Re: [Pharo-dev] why sparta depends on Taskit?

by stepharo

Hi doru > Hi, > > I think there are a couple of thinks that are mixed up. yes they both contribute to making bloc not accessible to mortals. > > First, the image from CI: > - download the latest image built on October 12 on Jenkins: > https://ci.inria.fr/pharo-contribution/job/Bloc/PHARO=60,VERSION=developmen… > - run it either with the stable of the latest VM > ==> you should get no crash when opening the image (I just checked again) It crashes with me systematically. May be this is not the latest stable vm. > The code loading is a bit strange. I just tried and I do now know why this does not work from the command line on Mac. For me it somehow hanged while loading PetitCSS. There is something strange with Metacello and projects that depend on Glamour that I could not quite fully understand yet and I am looking at it since a month. Dale, I need your help, but I will follow up on this :). At least I'm not the only one. guille told me that the problem is not in taskit because his jobs are fully working. > At the same time, I can reliably load the code using this script from a fresh Pharo image and the latest VM: Good to know > > Gofer it > smalltalkhubUser: 'Pharo' project: 'Bloc'; > configuration; > loadDevelopment. > > Can you please try this one? I will. Now I'm busy and since I cannot push little fixes I'm not really interested to lose time. I checked the code with the image glenn sent me and since there is not enough good class comments I decided that I will not invest. I'm kind of fed up losing my time reverse engineering other code. STef > Cheers, > Doru > > > >> On Nov 6, 2016, at 11:24 AM, stepharo <stepharo(a)free.fr> wrote: >> >> I got to the ci and I click on the image and download and drop it on my vm=> crash. >> Why doing a video? >> >> open a shell >> >> wget -O - http://get.pharo.org/60+vm | bash >> ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main ConfigurationOfBloc --install=development >> >> And it fails loading taskit. >> >> Stef >> >> >> >> >> Le 6/11/16 Ã 11:01, Aliaksei Syrel a Ã©crit : >>> The best would be if you could make a video of how you install Bloc and send to Glenn. Because it works for us and for Travis CI. Sound like you face a strange and not so easy to catch issue. >>> >>> Cheers >>> Alex >>> >>> >>> On Nov 5, 2016 6:54 PM, "stepharo" <stepharo(a)free.fr> wrote: >>> why sparta depends on Taskit? >>> >>> >>> Since I cannot load it I cannot try to understand. I find strange that a graphical canvas depends on a concurrent task management system. >>> >>> I tried to follow the instruction given by glenn and it failed. So so far I could not see any recent versions of Bloc. >>> >>> I do not understand why the image produced by the jenkins job crashes my vm. >>> >>> >>> Stef >>> >>> >>> wget -O - http://get.pharo.org/60+vm | bash >>> ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main ConfigurationOfBloc --install=development >>> >>> >>> just failed yesterday for me. >>> >>> > -- > www.tudorgirba.com > www.feenk.com > > "What we can governs what we wish." > > > > > >

Nov. 6, 2016

http://pharo.org/files/pharo.png

by Sven Van Caekenberghe

Who removed http://pharo.org/files/pharo.png ? Why ? It is used in tests/examples. Could it be put back please, even it is not used (it does do no harm) ? A basic rule of the Web is not to break existing stuff. Sven

Nov. 6, 2016

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Esteban Lorenzano

Hi Jan, Iâm sorry but I will not even look at it :( nothing personal, I respect a lot the instantiations people and their product (and I know they will do a good work). Is just that I care a lot about Pharo being open source MIT and I do not want to pollute my code with something I might have seen elsewhere (and copyrighted elsewhere)â¦ But of course, I can discuss my idea here and with whoever wants :) So, I have this idea who is very simple: keep structure offsets separately. Today all structure has something like this: height "This method was automatically generated" ^handle doubleAt: 17 height: anObject "This method was automatically generated" handle doubleAt: 17 put: anObject which of course does not work. with my idea this will become like this: height "This method was automatically generated" ^handle doubleAt: HEIGHT_OFFSET height: anObject "This method was automatically generated" handle doubleAt: HEIGHT_OFFSET put: anObject and HEIGHT_OFFSET can be initialised per sessionâ¦ or with a minimal intelligence per session with a âarchitecture changedâ verification. I think this is very easy to implement and will workâ¦ but of course I still didnât do anything more than think aboutâ¦ weâll see when I try to implement it :) Esteban > On 5 Nov 2016, at 17:05, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > Hi Esteban, > > Instantiations is also busy porting their VM to 64bits. They have already created a new API for OStructures so that the offsets are re calculated based on the platform alignment rules and the VM type [1]. > > I know Pharo is open source and VA Smalltalk is not. But a bit of cooperation should be possible I think. Both platforms benefit if libraries are easy to port and not re-inventing this wheel saves time. > > Jan. > > [1] http://www.instantiations.com/docs/862/wwhelp/wwhimpl/js/html/wwhelp.htm#hr… <http://www.instantiations.com/docs/862/wwhelp/wwhimpl/js/html/wwhelp.htm#hr…> > > > On Sat, Nov 5, 2016 at 3:10 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > > On 5 Nov 2016, at 12:27, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > > Le 05/11/2016 Ã 12:12, Jan van de Sandt a Ã©crit : > >> Hi, > >> > >> With the latest 64bits VM (201611042126) and image (60282) UFFI is also > >> looking good. I'm testing a small library of mine [1] to interface with > >> LMDB [1], a memory mapped key-value database. Almost all tests are > >> green. This is great progress! > > > > Hi Jan, > > > > did you have to change your UFFI definitions to match the 64bits version of your lib? > > no. > but structures do change (because of sizes, of course). > Iâm thinking a way to define a generic representation (keeping offsets somewhere instead hardcoding it), but for now they have to be redefined for each platform. > > Esteban > > > > > Thierry > > > >> I only ran into one issue, a PrimitiveFailed error with > >> #basicIdentityHash in the SmallFloat64 class. > >> > >> Cheers, > >> Jan. > >> > >> [1] http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB <http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB> > >> [2] https://symas.com/products/lightning-memory-mapped-database/ <https://symas.com/products/lightning-memory-mapped-database/> > >> > >> > >> On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> > >> <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: > >> > >> VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ <http://bintray.com/estebanlm/pharo-vm/build#files/> > >> <http://bintray.com/estebanlm/pharo-vm/build#files/ <http://bintray.com/estebanlm/pharo-vm/build#files/>> > >> Image here: http://files.pharo.org/get-files/60/pharo-64.zip <http://files.pharo.org/get-files/60/pharo-64.zip> > >> <http://files.pharo.org/get-files/60/pharo-64.zip <http://files.pharo.org/get-files/60/pharo-64.zip>> > >> > >> this is still not official (thatâs why is not in official place) so > >> there are a couple of known problems: > >> > >> - version format is different, and that breaks some things in image > >> that depends on it to know what happens > >> - command line is different and probably youâll need to play a bit > >> with options (one or two dashes). > >> - UFFI has some failing tests (but most of it works). > >> > >> I would appreciate some help to report and/or fix the emerging > >> problems. > >> > >> cheers, > >> Esteban > >> > >>> On 28 Oct 2016, at 10:39, Thierry Goubier > >>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com> <mailto:thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>> wrote: > >>> > >>> Hi all, > >>> > >>> anybody knows how to get (and test) the 64bits version of the > >>> Pharo vm and image? > >>> > >>> Thanks, > >>> > >>> Thierry > >> > >> > > > > > > >

Nov. 6, 2016

Re: [Pharo-dev] [Pharo-users] About balkanisation

by Tudor Girba

Hi Stef, I think that you are raising a valid point, and I actually agree with it. But I think there is another side of the coin as well. I think that right now we are in between worlds and this is not quite beneficial. Switching to GitHub is a significant effort, and treating it as business as usual will not work. That is why I think it is so important that we committed to the move for Pharo 7 and that we invest in the infrastructure. But, this will not be enough either if we do not get people to exercise it as soon as possible. To give an example. When the first version of Iceberg was announced, I started to use it for a couple of projects. I stumbled across problems that prevented me from working for several weeks. I could have easily switched to SmalltalkHub, but I did not. I connected with Nicolas and we worked through those problems. Btw, Nicolas is doing a wonderful job, and people should not take this for granted. He tends to be shy, so if you see him around, please give him a hug and let him know that we count on him. Or better yet, use Iceberg for your projects and send him your feedback :). I am sure that there are more problems ahead, and the only way to go through them is committing to go through them. This will push us back for a while, but I really believe in the promise once we get on the other side. I actually think that GitHub is not really a good match for Pharo from a conceptual point of view (the mismatch between what it offers and what we need is quite large), but it is an engineering decision that makes perfect sense for the future. So, yes, we should take GitHub with a grain of salt, and make it a goal to not change much our concept of what makes sense for Pharo. For example, we should not give up on having to resort to the file system. That is why it is so important to make Iceberg (this is not for you Stef because I know you know it, but for others :)). And I certainly agree that we should look for sane patterns, but as it goes with patterns, they emerge out of practice. I think we should aim for limiting the time of being in between the two worlds. It will not be pleasant, and we can only do it if we stick together and go through it as soon as possible. Cheers, Doru > On Nov 6, 2016, at 1:05 PM, stepharo <stepharo(a)free.fr> wrote: > > Hi > > I would like that you think a bit about our community and that there is a value in using common tools > > to share and develop common libraries. Because to me it feels like we are getting balkanize. > > > It may look super cool and be hyper trendy to use github (because like that you can say that you use latest hyper cool > > features), but I would like to ask especially people building libraries to pay attention that it is important > > that other people can contribute back easily and that there is an easy way to load/contribute. > > Today I experienced Bloc > > - I cannot load code and I cannot contribute. > > - I saw mdl with a mixture between smalltalkhub and github (sounds super hyper cool) and I saw paul not being able to contribute :( > > > Yes you can say that monticello sucks yes it is terrible yes we all fell like Cobol programmers but at the end of the day. > > Yes the herb is always greener elsewhere. Yes yes yes. Let us take some facts. > > We managed pharo and moose with it over the last 8 years successfully and Pharo and moose are not 5 packages together from > > what I can see. So pay attention about the decision you take. > > Now we will provide git support (this is 8 months that nicolas is exclusively working/thinking/dreaming > > about that) and that we are doing experiments (Guille is managing the bootstrap in github). > > Now when everybody will have its own little project lost on github (I do not count the amount of time I do not find pillar on github because I forget > > that it is called pillar-markup), what will we do. > > So we need an infrastructure to handle this and christophe is working on this. > > I think that you should consider the accidental complexity as something that we can minimise by using patterns and common practices. > > Now you can think that I'm an idiot and that I have no vision (be my guest) but we should pay attention because we are a small community. > > Stef > > > > -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

Nov. 6, 2016

Re: [Pharo-dev] why sparta depends on Taskit?

by Tudor Girba

Hi, I think there are a couple of thinks that are mixed up. First, the image from CI: - download the latest image built on October 12 on Jenkins: https://ci.inria.fr/pharo-contribution/job/Bloc/PHARO=60,VERSION=developmen… - run it either with the stable of the latest VM ==> you should get no crash when opening the image (I just checked again) The code loading is a bit strange. I just tried and I do now know why this does not work from the command line on Mac. For me it somehow hanged while loading PetitCSS. There is something strange with Metacello and projects that depend on Glamour that I could not quite fully understand yet and I am looking at it since a month. Dale, I need your help, but I will follow up on this :). At the same time, I can reliably load the code using this script from a fresh Pharo image and the latest VM: Gofer it smalltalkhubUser: 'Pharo' project: 'Bloc'; configuration; loadDevelopment. Can you please try this one? Cheers, Doru > On Nov 6, 2016, at 11:24 AM, stepharo <stepharo(a)free.fr> wrote: > > I got to the ci and I click on the image and download and drop it on my vm=> crash. > Why doing a video? > > open a shell > > wget -O - http://get.pharo.org/60+vm | bash > ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main ConfigurationOfBloc --install=development > > And it fails loading taskit. > > Stef > > > > > Le 6/11/16 Ã 11:01, Aliaksei Syrel a Ã©crit : >> The best would be if you could make a video of how you install Bloc and send to Glenn. Because it works for us and for Travis CI. Sound like you face a strange and not so easy to catch issue. >> >> Cheers >> Alex >> >> >> On Nov 5, 2016 6:54 PM, "stepharo" <stepharo(a)free.fr> wrote: >> why sparta depends on Taskit? >> >> >> Since I cannot load it I cannot try to understand. I find strange that a graphical canvas depends on a concurrent task management system. >> >> I tried to follow the instruction given by glenn and it failed. So so far I could not see any recent versions of Bloc. >> >> I do not understand why the image produced by the jenkins job crashes my vm. >> >> >> Stef >> >> >> wget -O - http://get.pharo.org/60+vm | bash >> ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main ConfigurationOfBloc --install=development >> >> >> just failed yesterday for me. >> >> > -- www.tudorgirba.com www.feenk.com "What we can governs what we wish."

Nov. 6, 2016

Re: [Pharo-dev] [Pharo-users] About balkanisation

by Dimitris Chloupis

> It may look super cool and be hyper trendy to use github (because like > that you can say that you use latest hyper cool > > features), but I would like to ask especially people building libraries > to pay attention that it is important > > that other people can contribute back easily and that there is an easy > way to load/contribute. > > > Indeed Git and Github are hypercool and trendy but the important question here is why. Why C++ is so popular, why Java is so popular, why Javascript is so popular, Why python is so popular. When you ask why you understand that being hyper cool, its not a thing, its not something you can glance over its a practical need we needed a language that is super fast with ability to handle complex code, C++ we needed a language that is focused on enterprise development , Java we needed a language to make web developent, Javascript we needed a language to simplify C/C++/Java and C# without losing libraries, Python we needed a superfast decentralized versions control systems for both code and other assets , Git we needed a place to host online open source projects with git , Github we needed the perfect language , the perfect libraries a tool to end all tools , Nothing each one of those hypercools excel in what you are doing, in many cases they are more than one, not because they are easy but because they are powerful. To go back to old alternatives would be like going back to caves because you have hard time opening the front door of your house. You may choose to go back to the cave but do not expect people to follow you. You preach people not to leave the comforts of the nest because its safe and it easy, but in the end I find that as wasted potential. The question I am asking myself everyday how far can Pharo go with taking advantage of modern technology, how far Pharo can go if it gains access to the same exact resources as all other programming languages ? What would it mean for the average Pharo developer to be able to use not just web dev libraries but any library, any tool , any programming language , any time ? If you can answer these questions then you know why embracing git and github is the right choice even if it pains you, even if makes you lose sleep sometimes or even if you find it hard. Just because Smalltalk is an island, Pharo does not need to be one. Afterall .... Pharo is not Smalltalk, or so we claim Its time to put our money where our mouths are.

Nov. 6, 2016

About balkanisation

by stepharo

Hi I would like that you think a bit about our community and that there is a value in using common tools to share and develop common libraries. Because to me it feels like we are getting balkanize. It may look super cool and be hyper trendy to use github (because like that you can say that you use latest hyper cool features), but I would like to ask especially people building libraries to pay attention that it is important that other people can contribute back easily and that there is an easy way to load/contribute. Today I experienced Bloc - I cannot load code and I cannot contribute. - I saw mdl with a mixture between smalltalkhub and github (sounds super hyper cool) and I saw paul not being able to contribute :( Yes you can say that monticello sucks yes it is terrible yes we all fell like Cobol programmers but at the end of the day. Yes the herb is always greener elsewhere. Yes yes yes. Let us take some facts. We managed pharo and moose with it over the last 8 years successfully and Pharo and moose are not 5 packages together from what I can see. So pay attention about the decision you take. Now we will provide git support (this is 8 months that nicolas is exclusively working/thinking/dreaming about that) and that we are doing experiments (Guille is managing the bootstrap in github). Now when everybody will have its own little project lost on github (I do not count the amount of time I do not find pillar on github because I forget that it is called pillar-markup), what will we do. So we need an infrastructure to handle this and christophe is working on this. I think that you should consider the accidental complexity as something that we can minimise by using patterns and common practices. Now you can think that I'm an idiot and that I have no vision (be my guest) but we should pay attention because we are a small community. Stef

Nov. 6, 2016

Re: [Pharo-dev] roundTo: strange behavior

by werner kassens

Hi Martin, yes, what i said was wrong (!). i got irritated when i used #printShowingDecimalPlaces: on a directly entered decimal number <g> and got a seemingly upwards rounded number. of course that result was also correct. iow there is no problem in the new #round: or #printShowingDecimalPlaces:. sorry for my confusion. werner On 11/06/2016 01:57 AM, Martin McClure wrote: > On 11/05/2016 06:17 AM, werner kassens wrote: >> Hi, >> fwiw when i redid that #testIfCompletelyBroken i noticed a sort of >> bug in that new #round: - well, i think its a feature -, but i should >> probably mention it nevertheless: >> 1.15 round:1. "1.1" "down" >> 1.25 round:1. "1.3" "up" >> 1.35 round:1. "1.4" "up" >> 1.45 round:1. "1.4" "down" >> 1.55 round:1. "1.6" "up" >> 1.65 round:1. "1.6" "down" >> btw the same happens with #printShowingDecimalPlaces: (which is >> unchanged, happens eg also in 4.0). >> >> if one wants to change this to the normal behaviour, i'd guess one >> could do it perhaps by using #asMinimalDecimalFraction instead of >> #asFraction in #round: > > > This is, in part, an example of it being difficult to predict, at a > glance, what #round: should do, without an understanding of the > strengths and limitations of binary floating point numbers. > > Remember that Floats are not usually exact representations of nice > decimal fractions. So most of these numbers are not *exactly* halfway > between their possible roundings. > > 1.15 < (115/100) "true" > 1.25 = (125/100) "true" > 1.35 > (135/100) "true" > 1.45 < (145/100) "true" > 1.55 > (155/100) "true" > 1.65 < (165/100) "true" > > In every case except 1.25, the answer is the correct rounding, that, > is the one that is closer. For 1.25, the number *is* exactly halfway > between two roundings. For round-to-even (which I recommend) the > answer should be 1.2, so it gets that one "wrong". > > Regards, > > -Martin > > >

Nov. 6, 2016

Re: [Pharo-dev] [Bloc] Hierarchy of BiEvent

by stepharo

Le 27/10/16 Ã 10:57, Guille Polito a Ã©crit : > Something itches me from this discussion. > > I somehow find myself with Glenn: > - should Bloc work with other than SDL/OSWindow? > - should SDL/OSWindow work with other than Bloc? > > Merging the event hierarchy may prevent these two scenarios. And these > scenarios are not only really possible: this is what the current > scenario is. On one hand SDL and OSWindow work today with Morphic > besides Block. On the other hand Bloc is, after all, an external > library loaded on top of Pharo. > > To explain better what I think: > > - First I have the feeling that BIEvent and OSEvent are not the same > thing. They have the same *NAME*. But they model different concepts. > What is an event in bloc does not make sense in OSWindow and > vice-versa. Why? because OSWindow does not manage widgets nor > interactions between them. > > - Second, I think that this idea of merging these hierarchies means > merging layers also, what leads also to our monolithic system. I agree > that this may impose some maintenance burden because there is the > maintenance of the two layers plus their mapping (e.g., between the > low-level events and the high-level events). But otherwise we are > tampering the modularity. > > Now, I liked more the suggestion of making Bloc using SDLEvents directly. > > But then, wasn't it an idea behind OSWindow that users of OSWindow > should be somehow abstracted from the backend behind. And SDL be just > a backend? Something like Athens and Cairo. > > Is SDL meant to work alone or be just a backend for OSWindow? Because > if the case is the later, then maybe it makes sense to do the inverse: > SDL should generate directly OSEvents and we should not have SDLEvent. may be. Now I do not think that doing more than two transformations is good. > And going even further: Is OSWindow used in isolation? e.g., without > morphic or bloc. > > Because then, it the problem is the runtime overhead OSWindow should > maybe not reify its events but propose a low level event handler > mechanism where we could have > > MorphicOSWindowEventHandler > >> keyEvent: ... > >> mouseEvent: ... > > BlocOSWindowEventHandler > >> keyEvent: ... > >> mouseEvent: ... > > And each framework generates its own events from low level SDL data. > No event transformations, less duplications, and both Bloc and Morphic > are plugged on top of OSWindow but not really strongly coupled to it. may be

Nov. 6, 2016