- Pharo-users - lists.pharo.org

Re: [Pharo-users] No, the installation of Pharo is not large its actually small

by Dimitris Chloupis

obviously not, added them as a reference for the comparison ;) On Wed, Nov 2, 2016 at 12:19 PM Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-11-02 11:04 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > > So No, the Pharo installation is not large its actually small . You think > I am joking ? Ok lets take a look at some of the most popular programming > languages out there > > 1) Pharo = 100 MBs > 2) Cuis = 70 MBs > > > some of the most popular programming languages :) >

Nov. 2, 2016

Re: [Pharo-users] No, the installation of Pharo is not large its actually small

by Dimitris Chloupis

Oups sorry you meant just Pharo, I have a clean build of Pharo 6 (latest VM- latest image) every day so its easy to check the total size of the folder. Its 47 MBs for the image , 43 MBs for the vm (including plugins) and the rest is just 10 mbs of various things.

Nov. 2, 2016

Re: [Pharo-users] No, the installation of Pharo is not large its actually small

by Dimitris Chloupis

The numbers are widely available online , since most software comes with minimum system requirements. .NET was the only real challenge because Microsoft tries to mislead you into thinking its small by saying the installer is few MBs , BUT, the installer obviously is a web installer and it depends on previous installations of .NET. Here some links http://stackoverflow.com/questions/21230657/what-is-the-current-full-instal… https://www.quora.com/What-is-the-size-and-how-long-does-it-take-Visual-Stu… http://docwiki.embarcadero.com/RADStudio/Seattle/en/Installation_Notes etc For Pharo, Cuis, Lua, Python, Ruby , Gambas and XCODE I have them installed so I can directly verify and confirm these number. I can also switch to my Windows boot to confirm Visual Studio and .NET but I dont have too since I have a rough idea because I installed the Windows boot a week ago and I remember how long the installs took. > >

Nov. 2, 2016

Re: [Pharo-users] No, the installation of Pharo is not large its actually small

by Denis Kudriashov

2016-11-02 11:04 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > So No, the Pharo installation is not large its actually small . You think > I am joking ? Ok lets take a look at some of the most popular programming > languages out there > > 1) Pharo = 100 MBs > 2) Cuis = 70 MBs > some of the most popular programming languages :)

Nov. 2, 2016

Re: [Pharo-users] No, the installation of Pharo is not large its actually small

by Esteban Lorenzano

> On 2 Nov 2016, at 11:04, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > So No, the Pharo installation is not large its actually small . You think I am joking ? Ok lets take a look at some of the most popular programming languages out there > > 1) Pharo = 100 MBs where do you get this number? (not to say that also Pharo is like Java+Eclipse+Tomcat+â¦) Esteban > 2) Cuis = 70 MBs > 3) Python = 100MBs > 4) Java = 120 MBbs > 5) .NET = 240Mbs > 6) Ruby , source code folder alone 92mb , with build 200mbs > 7) Javascript , Firefox = 200 MBs > > > and it does not stop there, because none of the above is similar to Pharo, they dont come with IDEs so lets take a look at programming languages packaged with IDEs > > 1) Visual Studio (C++, C#, Visual Basic etc) 7 GBs > 2) XCode (ObjC, Swift , C/C++ [clang]) 13 GBs > 3) Delphi = 2 GBs ( not including .NET) > 4) Gambas , source code alone 60 MBs (Visual Basic 6 free software clone) , cant build it on MacOS > 5) Cygwin , ranges from 100 mbs to 100 GBs > > Of course that does not mean that extremely small installs do not exist, they do > > An example is Lua, the Lua executable is only 300 KBs (300 times smaller than Pharo) but its super bare bones (no IDE, no GUI , no GUI API, no standard library, no version control, pretty much nothing)

Nov. 2, 2016

No, the installation of Pharo is not large its actually small

by Dimitris Chloupis

So No, the Pharo installation is not large its actually small . You think I am joking ? Ok lets take a look at some of the most popular programming languages out there 1) Pharo = 100 MBs 2) Cuis = 70 MBs 3) Python = 100MBs 4) Java = 120 MBbs 5) .NET = 240Mbs 6) Ruby , source code folder alone 92mb , with build 200mbs 7) Javascript , Firefox = 200 MBs and it does not stop there, because none of the above is similar to Pharo, they dont come with IDEs so lets take a look at programming languages packaged with IDEs 1) Visual Studio (C++, C#, Visual Basic etc) 7 GBs 2) XCode (ObjC, Swift , C/C++ [clang]) 13 GBs 3) Delphi = 2 GBs ( not including .NET) 4) Gambas , source code alone 60 MBs (Visual Basic 6 free software clone) , cant build it on MacOS 5) Cygwin , ranges from 100 mbs to 100 GBs Of course that does not mean that extremely small installs do not exist, they do An example is Lua, the Lua executable is only 300 KBs (300 times smaller than Pharo) but its super bare bones (no IDE, no GUI , no GUI API, no standard library, no version control, pretty much nothing)

Nov. 2, 2016

Re: [Pharo-users] Keeping data with an application

by Dale Henrichs

On 11/1/16 12:28 PM, sergio ruiz wrote: > Okay.. is Voyage ready to rock and/or roll? Voyage is definitely ready to rock and roll ... Voyage/Tugrik is ready to be rocked ... it is functional and passes the tests (on Pharo5.0). For this project, I want to make progress based on feedback from users ... there are lots of different directions that could be taken from this starting point and I want to be driven by user feedback ... so if you are willing to provide feedback I am willing to work with you ... The only change that I think I need to make is to improve the session pool logic ... it works fine, but the session boundary is not quite at right level to make the best use of GemStone sessions ... With "direct access" to the server objects via Voyage Server Blocks I think that query api provided by MongoTalk may not be that interesting, but this is the kind of information I am looking for from users ... If MongoTalk _is_ interesting then you should know that I did not try to fill out the full MongoDB query language, yet ... I implemented the features excercised by tests, so if you hit something that you you find lacking then I will plug the gap ... it is relatively straight forward to implement the MongoDB query language (except for the bits that rely directly on the javascript language:) so it shouldn't take too long to fill in holes:) > > is today your birthday? for some reason, i got a notification of > several things on my machine today.. one of those being your birthday.. > > if so, happy birthday! Tomorrow is my birthday, thanks:) > > if not.. happy un-birthday! > > Dale

Nov. 1, 2016

Re: [Pharo-users] Keeping data with an application

by sergio ruiz

Okay.. is Voyage ready to rock and/or roll? is today your birthday? for some reason, i got a notification of several things on my machine today.. one of those being your birthday.. if so, happy birthday! if not.. happy un-birthday! On November 1, 2016 at 2:16:57 PM, Dale Henrichs (dale.henrichs(a)gemtalksystems.com) wrote: You might take a look at the talk I gave on Voyage/Tugrik at ESUG(slides[1], video[2]). The project is in a functional, but roughed out stage ---- 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

Nov. 1, 2016

Re: [Pharo-users] Keeping data with an application

by Dale Henrichs

Sergio, You might take a look at the talk I gave on Voyage/Tugrik at ESUG(slides[1], video[2]). The project is in a functional, but roughed out stage --- but the main idea behind it is that with GemStone as the db serve, you are dealing with Smalltalk objects on both the client and server ... Voyage Server Blocks allow you to write code on the client that is executed against objects on the server ... STON is used for serialization/materialization ... Voyage Server Blocks let you blur the lines as to where do the objects live and where does the code execute ... Currently Tugrik uses MongoTalk as the model for Voyage-style interactions between client and server, but Voyage Server Blocks (which are not a feature of MongoTalk) may be useful on their own ... In the talk, I mention that I am looking for partners in pushing Voyage/Tugrik forward, because I think that real users with real problems are needed to drive the project forward --- I am more interested in meeting real developer needs, than building something that makes me happy:) MongoTalk was originally chosen to make it practical for folks already using Voyage/Mongo to easily kick the tires on Voyage/Tugrik, but I don't think that it is necessary to stay coupled to MongoTalk. Michal Balda is looking at something "simpler than Tugrik+MongoTalk+Voyage" and I wish that I could be in Zurich to see his presentation next week[3]:) as I want to support his efforts ... Dale [1] http://www.slideshare.net/esug/tugrik-a-new-persistence-option-for-pharo [2] https://www.youtube.com/watch?v=YwlUdRaqTwE&feature=youtu.be [3] http://forum.world.st/ANN-Zurich-Smalltalk-Meetup-Nov-8th-2016-tt4919147.ht… On 11/01/2016 08:54 AM, sergio ruiz wrote: > Hey, all.. > > One of the things that I find SUPER necessary when developing an app > is to be able to grab data from somewhere else and quickly and easily > work on it from my machine. > > For instance, when I get a bug report that smells funny, the first > thing i sometimes do is run a script that grabs the production data, > and populates my local database with that data. > > i am fleshing out a project that i would really like to use Teapot > (REST) for. i could then write several front ends in whatever > framework/language. > > I was thinking about using Voyager, but the problem is, the data is > VERY relational (see below, if interested).. objects are linked to > each other fairly tightly. I donât know if this would be the way to > handle the data, as there would be lots of duplication using mongodb > as a datastore. > > Of course, my first thought is Gemstones, but I donât know how to grab > the production data and pull it into my local development system. > > Does anyone have any thoughts on this? > > For those curious about the data design, i am setting up a REST server > for an collaborative internet radio applicationâ¦ > > - there would be a global pool of stations (just streaming urls with > metadata, really) > - each user can select from or contribute to the global pool > - users can add tags to stations (or search through the global > stations based on tags) > - users can attach comments to stations > > not complex or intimidating at all, and super easy to model in > smalltalk, but not sure about how to store data so that I can quickly > grab production data and troubleshoot if if necessary. > > 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

Nov. 1, 2016

Re: [Pharo-users] How does Boolean ifTrue work?

by Igor Stasenko

On 1 November 2016 at 17:00, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Hey Igor is around \o/ > Hey heya! :) > BTW using size = 0 triggers a code critic telling you to use isEmpty. > > Maybe there is a rule of isEmpty ifTrue: :-) > > I think that there could be a lot of convenience methods in the base > image. They can be in an extension protocol, no issue. STON and gt have a > ton of these. In the base image. > > About beginners, well: have a look in some Zinc code and learn a truckload > of tricks. Like inject: somePath into: ... etc. > > And when puzzled, Halt now and debug or inspect it go a long way in > figuring things out. > > As long as the method is intention revealing, what is the issue? > > At the risk of some flames, Pharo isn't bound to some Smalltalk > compatibility. And that is what is cool about it. We chose another path now > we have to go our way of else. > > Building on a great foundation is nice. But that doesn't equate to > following the Smalltalk canon IMHO. > > And now 64 bits becoming real with a nice FFI and pinned objects... that > is going to bring in a lot of non smalltalk stuff for sure. > > Phil > > well, if continue on that, i think that while #ifEmpty: is perfectly fine, the #ifEmptyOrNil: are not. And indeed, in this case im also inclined to see those as pollution. Because uninitialized state can (or better to say - *must*) happen in one form - either it is nil, or empty collection, but not both. If your code having entry points that treats both of those as some kind of uninitialized state, then i would call it bad. To my opinion, it is bad practice to declare 'my method(s) can deal with any shit you can throw into it'. Personally, i prefer to clearly state what it accepting and what not, and strongly discourage any other free-form inputs, or even better - making them impossible to appear, so you don't have to put #ifEmptyOrNilOrCrazy: everywhere to make your code idioto-proof :) And the stupidity-proofing is quite simple, use converters/validators immediately on passed external data: myMethod: externalData myValidState := externalData asSanelyCheckedData. so, like that you don't have to put: myValidState ifValidState: [] everywhere :) Le 1 nov. 2016 15:14, "Igor Stasenko" <siguctua(a)gmail.com> a Ã©crit : > >> >> >> On 1 November 2016 at 11:31, jtuchel(a)objektfabrik.de < >> jtuchel(a)objektfabrik.de> wrote: >> >>> Phil, >>> >>> >>> I see your point but disagree. >>> I don't use Pharo regularly, so I cannot currently check if the >>> implementation around this emptiness check is complete. >>> >>> With complete I mean that following your logic, theere should be at >>> least implementations of >>> >>> ifEmpty: >>> ifNotEmpty: >>> ifEmpty:ifNotEmpty: >>> ifEmptyOrNil: >>> ifEmptyOrNil:otherwise: >>> >> >> why pollution? >> it just convenience method. mind you, that #isEmpty is also convenience >> method, without it you would do it like: >> >> myArray size isZero ifTrue: [] >> of wait.. #isZero also convenience method... so if you elitist then you >> have to write it like that: >> >> myArray size = 0 ifTrue: [] >> >> And that , to my opinion, adds even more pollution to the user code, >> because first, it is longer, and second >> #ifEmpty: much better clarifies the intent of author, comparing to size = >> 0 >> >> >>> I really have to check for the size of collections very often, and the >>> size of 1 is a very frequent case. So why not add: >>> >>> ifExactlyOne: >>> ifSizeIs:do: >>> ifSizeIsGreaterThan:do:otherwiseDo: >>> >>> You get the picture. I strongly believe this leads to pollution and ends >>> up in a mess. >>> We could save so much typing and make our programs so much more readable >>> if we only were a bit more creative, right? ;-) >>> A DSL is another story, though. If you write a Library that makes >>> handling Collections nicer, this is okay and the methods are good to exist >>> in its context. But they shouldn't necessarily all be part of the base >>> image. >>> >>> >>> Don't get me wrong: if you and the Pharo community agree on lots of >>> convenience methods, that is okay for me, and I find myself adding such >>> methods to VA Smalltalk from time to time. I appreciate many of them being >>> brought to VA ST in Grease. >>> >>> Sometimes, this is simply a question of taste, sometimes it saves >>> typing, sometimes it helps to improve readability of code. >>> >>> But I wouldn't go so far to tell people they should better use such a >>> method as a general advice. I would probably tell them: "look, here's a >>> method I find much more elegant, you could *also* use that to save >>> typing/increase readability". >>> >>> Just my 2 cents, and highly off topic ;-) >>> >>> Joachim >>> >>> >>> >>> >>> Am 01.11.16 um 08:43 schrieb phil(a)highoctane.be: >>> >>> Because I grew tired of the isEmpty ifTrue: [ ] all over the place. >>> And ifEmpty has the right semantics for my use cases (like assignment). >>> >>> I do not really care about portability, I am doing Pharo only. >>> >>> Phil >>> >>> On Mon, Oct 31, 2016 at 5:30 PM, jtuchel(a)objektfabrik.de < >>> jtuchel(a)objektfabrik.de> wrote: >>> >>>> Am 31.10.16 um 15:59 schrieb phil(a)highoctane.be: >>>> >>>> but you should use myCollection ifEmpty: [ ... ] >>>> >>>> >>>> interesting. Why do you think so? what if you wanted your code to be >>>> portable across Smalltalk dialects? >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> ----------------------------------------------------------------------- >>>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <jtuchel(a)objektfabrik.de> >>>> Fliederweg 1 http://www.objektfabrik.de >>>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >>>> >>>> >>>> -- >>> ----------------------------------------------------------------------- >>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <jtuchel(a)objektfabrik.de> >>> Fliederweg 1 http://www.objektfabrik.de >>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Nov. 1, 2016