October 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] Sparta v1.1

by stepharo

This is what christophe is doing in cargo. Stef Le 22/10/16 Ã 17:29, phil(a)highoctane.be a Ã©crit : > Looks like we are on the same wavelength but... > > Look how this is done in PHP with Composer: > > - simple Json file > - declares repositories > - requires and requiresdev > - uses semver versions > > so, 'composer install' will fetch and install deps. > > composer update will update deps. > > composer.json > { > "name": "zendframework/skeleton-application", > "description": "Skeleton Application for ZF2", > "license": "BSD-3-Clause", > "keywords": [ > "framework", > "zf2" > ], > "homepage": "http://framework.zend.com/", > "repositories": [{ > "type": "vcs", > "url": "https://github.com/RobLoach/firephp-core" > }], > "require": { > "php": ">=5.5", > "zendframework/zendframework": "~2.5", > "zendframework/zftool": "dev-master", > "firephp/firephp-core": "dev-master", > "videlalvaro/php-amqplib": "^2.5" > }, > "require-dev": { > "snapshotpl/zf-snap-event-debugger": "1.*", > "zendframework/zend-developer-tools": "dev-master", > "phpunit/phpunit": "4.8.*" > } > } > > In the JS Ecosystem, eg. bower.json > > { > "name": "adsdaq", > "homepage": "https://github.com/anais-it/adsdaq", > "authors": [ > "Philippe Back <phil(a)highoctane.be <mailto:phil@highoctane.be>>" > ], > "description": "adsdaq-frontend", > "main": "", > "moduleType": [], > "license": "Adlogix", > "private": true, > "ignore": [ > "**/.*", > "node_modules", > "bower_components", > "vendor/bower_components", > "test", > "tests" > ], > "dependencies": { > "angular": "~1.4.7", > "restangular": "~1.5.1", > "lodash": "~3.10.1", > "angular-route": "~1.4.7", > "angular-spinner": "~0.8.0", > "angular-bootstrap": "~0.14.3", > "typeahead.js": "~0.11.1" > } > } > > > So, basic module names in deps and semver. > > The st code you show is more cryptic. > > Is there a sweet spot ? > > Ston is a great format and is Json compatible if we are careful > (meaning I can actually use vim and json syntax checkers plugins) > > St code is indeed more powerful but it leaves a lot of people in the > dust with configurations. > > What do you think? > > Phil > > > > > On Sat, Oct 22, 2016 at 3:17 PM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > > > On 10/22/16 12:04 AM, phil(a)highoctane.be > <mailto:phil@highoctane.be> wrote: >> We need some easy to use gem-style installer on the command line. > Phil, > > Since I am not really familiar with ruby, I'm not sure what you > mean by "gem-style installer on the command line"? > > Depending upon what you mean, I think I agree:) > > For GsDevKit_home[1], I have arranged for bash scripts that can be > used for building both stones and clients for GemStone. Here are > the example scripts for Tugrik[2]: > > |# Create Tugrik stone createStone -u > http://gsdevkit.github.io/GsDevKit_home/Tugrik.ston > <http://gsdevkit.github.io/GsDevKit_home/Tugrik.ston> -i Tugrik -l > Tugrik Tugrik 3.3.0 # Create Tugrik Pharo5.0 client createClient > -t pharo tugrik -l -v Pharo5.0 -z > $GS_HOME/shared/repos/Tugrik/.smalltalk.ston| > > The Tugrik.ston file is a tODE object looks like the following[1] > when materialized (basically a Metacello load script with > additional info): ^ TDProjectSpecEntryDefinition new > baseline: 'Tugrik' repository: > 'github://dalehenrich/Tugrik:master/repository' loads: > #('default'); installScript: ' project install --local > --url=http://gsdevkit.github.io/GsDevKit_home/MongoTalk.ston > <http://gsdevkit.github.io/GsDevKit_home/MongoTalk.ston> > project clone --https --local Tugrik'; postLoadScript: 'mount > @/sys/stone/dirs/Tugrik/gsdevkit/tode /home tugrik'; status: > #(#'inactive'); locked: false; yourself Their are fields > for comments and a project url as well ... obviously other fields > are possible ... the cool thing about this is that is a > specification for a load rather than a Smalltalk load expression > ... which means the repository can easily be re-targetted or the > loads list changed, etc. Since Pharo doesn't have tODE:), I > leverage the SmalltalkCI[4] configuration file for Tugrik[5], > which looks like this: SmalltalkCISpec { #loading : [ > SCIMetacelloLoadSpec { #baseline : 'Tugrik', #load : [ > 'CI' ], #onWarningLog : true, #directory : > 'repository', #platforms : [ #gemstone, #pharo ] } ], > #configuring : [ SCIGemStoneServerConfigSpec { > #defaultSessionName : 'Tugrik', #platforms : [ > #gemstoneClient ] } ] } Very similar information, but has > the advantage of being usable in GemStone, Squeak and Pharo ... I > have an option for creating stones using a SmalltalkCI > configuration file as well ... I've been thinking that I could add > a MetacelloProjectLoadSpecification class to Metacello that is > meant to be passed around as an object in STON format that > combines the good bits of the TDProjectSpecEntryDefinition with > the good bits of the SCIMetacelloLoadSpec and be available in > GemStone, Pharo and Squeak ... then you'd just send #load to the > object to trigger the install ... Is there anything in the > "gem-style installer on the command line"that I'm missing? Am I > completely off-base? Dale [1] > https://github.com/GsDevKit/GsDevKit_home#open-source-development-kit-for-g… > <https://github.com/GsDevKit/GsDevKit_home#open-source-development-kit-for-g…>- > [2] > https://github.com/dalehenrich/Tugrik#create-tugrik-stone-and-client > <https://github.com/dalehenrich/Tugrik#create-tugrik-stone-and-client> > [3] > https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Tugrik.ston > <https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Tugrik.ston> > [4] https://github.com/hpi-swa/smalltalkCI#smalltalkci > <https://github.com/hpi-swa/smalltalkCI#smalltalkci>--- [5] > https://github.com/dalehenrich/Tugrik/blob/master/.smalltalk.ston > <https://github.com/dalehenrich/Tugrik/blob/master/.smalltalk.ston> >

Oct. 22, 2016

Re: [Pharo-dev] Again about scrolling with a trackpad

by stepharo

Denis this is why I asked you do improve the FT for spec because like that ALL the spec tools will be fixed in one shot. Stef Le 21/10/16 Ã 16:08, Denis Kudriashov a Ã©crit : > Hi Yuriy. > > I just want to say that I feel completely same. > And I am sure that problem with Nautilus. I am working on remote > browser where I just use FastTable and never saw any problem with > scrolling. > > 2016-10-21 15:56 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com > <mailto:yuriy.tymchuk@me.com>>: > > Ok, > > there is a problem that when you use trackpad with pharo and you > scroll something strange happens. And it was documented that when > you scroll sideways itâs registered as ctrl + arrow click and it > switches focus. > > Now it seems that on Siera it became worse because now I cannot > normally scroll at all. > > Additionally this causes a lot of problems: i.e. when someone > wanted to remove history plugin from nautilus many of people > protested because when your navigation is fucked up during > scrolling you can get back. > > Now I started to think: why wonât we simply delete the code that > registers these events. So I have a question, does anybody find > this functionality useful? I find it super frustrating. And if > everyone else does, maybe we can simply remove that. > > Also while the time passes, does anybody have any idea on how to > hack Pharo to ignore these events? Because I need to work and I > can notâ¦ > > Cheers. > Uko > >

Oct. 22, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by stepharo

Hi aliaksei I thought that you were just changing the internal representation of txText to use Ropes and building on top of / improving txText I did not think that you were throwing away all the work igor did. Because he spent a lot of time designing the text model and making it is scalable - and now I read that apparently it was not scalable enough. I'm wondering what will happen if suddenly you disappear: we will get two unfinished textmodel and use an old one? When do you think that you will have a working usable by other for real text model? Stef Le 22/10/16 Ã 12:29, Aliaksei Syrel a Ã©crit : > As Doru already mentioned text editor is an important part of the > tools. There are some requirements a text editor should fulfil. > > 1. Support of large files ( >> 100mb) > 2. Support of large pieces of text located in memory > 3. Allow developers to embed visual elements (pictures, interactive > elements, custom elements) > 4. Support of more sophisticated layouts rather than line-based. For > example columns. > 5. Line breaking > 6. Text wrapping > 7. Hyphens > 8. Should be fast > > Tests show that TxText model is very nice for basic cases, works well > for "normal" use. > However, when it comes to extreme cases linked list of spans just > fails, while rope shows great performance - and it also scales. > > Cheers, > Alex > > On 19 October 2016 at 23:51, Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>> wrote: > > > 2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com > <mailto:alex.syrel@gmail.com>>: > > - Added initial text support, for instance rendering and high > precision measurement. > > > I look at code and it seems you implemented another one new text > model? Why you not use TxText? > >

Oct. 22, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by Dale Henrichs

I wholeheartedly agree that Smalltalk is not desirable as a specification language ... I included the Smalltalk expression as an example of the type of information I am using in tODE (when I make another pass through tODE I will switch from smalltalk to STON) ... So moving forward I think a STON-based project load spec is preferable. See my reply to Esteban for an example of the types of information that I imagine would be included in a project load spec. Looking closely at the below, I think including the license is a good idea... Now it seems to me that both`compose install` and `bower install` don't do much more that automatic `git clone` ... is that right? I have toyed with the idea that a BaselineOf could be represented as a STON file (or XML file), but right now I tend to think that there isn't much difference in the readability/simplicity between Smalltalk and STON ... STON might be a bit more sparse, but without a tool for writing STON files (syntax validation and automatic saving ... to disk????) so I will stick with Smalltalk for the foreseeable future:) Dale On 10/22/16 8:29 AM, phil(a)highoctane.be wrote: > Looks like we are on the same wavelength but... > > Look how this is done in PHP with Composer: > > - simple Json file > - declares repositories > - requires and requiresdev > - uses semver versions > > so, 'composer install' will fetch and install deps. > > composer update will update deps. > > composer.json > { > "name": "zendframework/skeleton-application", > "description": "Skeleton Application for ZF2", > "license": "BSD-3-Clause", > "keywords": [ > "framework", > "zf2" > ], > "homepage": "http://framework.zend.com/", > "repositories": [{ > "type": "vcs", > "url": "https://github.com/RobLoach/firephp-core" > }], > "require": { > "php": ">=5.5", > "zendframework/zendframework": "~2.5", > "zendframework/zftool": "dev-master", > "firephp/firephp-core": "dev-master", > "videlalvaro/php-amqplib": "^2.5" > }, > "require-dev": { > "snapshotpl/zf-snap-event-debugger": "1.*", > "zendframework/zend-developer-tools": "dev-master", > "phpunit/phpunit": "4.8.*" > } > } > > In the JS Ecosystem, eg. bower.json > > { > "name": "adsdaq", > "homepage": "https://github.com/anais-it/adsdaq", > "authors": [ > "Philippe Back <phil(a)highoctane.be <mailto:phil@highoctane.be>>" > ], > "description": "adsdaq-frontend", > "main": "", > "moduleType": [], > "license": "Adlogix", > "private": true, > "ignore": [ > "**/.*", > "node_modules", > "bower_components", > "vendor/bower_components", > "test", > "tests" > ], > "dependencies": { > "angular": "~1.4.7", > "restangular": "~1.5.1", > "lodash": "~3.10.1", > "angular-route": "~1.4.7", > "angular-spinner": "~0.8.0", > "angular-bootstrap": "~0.14.3", > "typeahead.js": "~0.11.1" > } > } > > > So, basic module names in deps and semver. > > The st code you show is more cryptic. > > Is there a sweet spot ? > > Ston is a great format and is Json compatible if we are careful > (meaning I can actually use vim and json syntax checkers plugins) > > St code is indeed more powerful but it leaves a lot of people in the > dust with configurations. > > What do you think? > > Phil > > > > > On Sat, Oct 22, 2016 at 3:17 PM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > > > On 10/22/16 12:04 AM, phil(a)highoctane.be > <mailto:phil@highoctane.be> wrote: >> We need some easy to use gem-style installer on the command line. > Phil, > > Since I am not really familiar with ruby, I'm not sure what you > mean by "gem-style installer on the command line"? > > Depending upon what you mean, I think I agree:) > > For GsDevKit_home[1], I have arranged for bash scripts that can be > used for building both stones and clients for GemStone. Here are > the example scripts for Tugrik[2]: > > |# Create Tugrik stone createStone -u > http://gsdevkit.github.io/GsDevKit_home/Tugrik.ston > <http://gsdevkit.github.io/GsDevKit_home/Tugrik.ston> -i Tugrik -l > Tugrik Tugrik 3.3.0 # Create Tugrik Pharo5.0 client createClient > -t pharo tugrik -l -v Pharo5.0 -z > $GS_HOME/shared/repos/Tugrik/.smalltalk.ston| > > The Tugrik.ston file is a tODE object looks like the following[1] > when materialized (basically a Metacello load script with > additional info): ^ TDProjectSpecEntryDefinition new > baseline: 'Tugrik' repository: > 'github://dalehenrich/Tugrik:master/repository' loads: > #('default'); installScript: ' project install --local > --url=http://gsdevkit.github.io/GsDevKit_home/MongoTalk.ston > <http://gsdevkit.github.io/GsDevKit_home/MongoTalk.ston> > project clone --https --local Tugrik'; postLoadScript: 'mount > @/sys/stone/dirs/Tugrik/gsdevkit/tode /home tugrik'; status: > #(#'inactive'); locked: false; yourself Their are fields > for comments and a project url as well ... obviously other fields > are possible ... the cool thing about this is that is a > specification for a load rather than a Smalltalk load expression > ... which means the repository can easily be re-targetted or the > loads list changed, etc. Since Pharo doesn't have tODE:), I > leverage the SmalltalkCI[4] configuration file for Tugrik[5], > which looks like this: SmalltalkCISpec { #loading : [ > SCIMetacelloLoadSpec { #baseline : 'Tugrik', #load : [ > 'CI' ], #onWarningLog : true, #directory : > 'repository', #platforms : [ #gemstone, #pharo ] } ], > #configuring : [ SCIGemStoneServerConfigSpec { > #defaultSessionName : 'Tugrik', #platforms : [ > #gemstoneClient ] } ] } Very similar information, but has > the advantage of being usable in GemStone, Squeak and Pharo ... I > have an option for creating stones using a SmalltalkCI > configuration file as well ... I've been thinking that I could add > a MetacelloProjectLoadSpecification class to Metacello that is > meant to be passed around as an object in STON format that > combines the good bits of the TDProjectSpecEntryDefinition with > the good bits of the SCIMetacelloLoadSpec and be available in > GemStone, Pharo and Squeak ... then you'd just send #load to the > object to trigger the install ... Is there anything in the > "gem-style installer on the command line"that I'm missing? Am I > completely off-base? Dale [1] > https://github.com/GsDevKit/GsDevKit_home#open-source-development-kit-for-g… > <https://github.com/GsDevKit/GsDevKit_home#open-source-development-kit-for-g…>- > [2] > https://github.com/dalehenrich/Tugrik#create-tugrik-stone-and-client > <https://github.com/dalehenrich/Tugrik#create-tugrik-stone-and-client> > [3] > https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Tugrik.ston > <https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Tugrik.ston> > [4] https://github.com/hpi-swa/smalltalkCI#smalltalkci > <https://github.com/hpi-swa/smalltalkCI#smalltalkci>--- [5] > https://github.com/dalehenrich/Tugrik/blob/master/.smalltalk.ston > <https://github.com/dalehenrich/Tugrik/blob/master/.smalltalk.ston> >

Oct. 22, 2016

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

by stepharo

Le 22/10/16 Ã 17:21, phil(a)highoctane.be a Ã©crit : > The st command line handler is pretty much giving the same. > > I used scale, it works nicely indeed. > > But I want Coral reborn. me too. Damien is working on a new command line parser. > > Phil > > On Sat, Oct 22, 2016 at 12:41 PM, Dimitris Chloupis > <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > > This link may interest you command line people , it basically what > I proposed as an idea early on > > https://github.com/guillep/Scale <https://github.com/guillep/Scale> > > On Sat, 22 Oct 2016 at 13:20, Dimitris Chloupis > <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > > I was replying to Thierry saying that we had issues with Pharo > mixing metarepo6 with metarepo5 > On Sat, 22 Oct 2016 at 13:11, Esteban Lorenzano > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > >> On 22 Oct 2016, at 12:00, Dimitris Chloupis >> <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >> >> Didn't Esteban fixed metarepo ? I think I remember him >> saying that he did. > > fixed in what sense? > > Esteban > >

Oct. 22, 2016

Re: [Pharo-dev] [ANN] Sparta v1.1

by stepharo

Superb Phil. PS: For the record: we are working on - bootstrap core and we are making progress - Git support - package manager and distribution building Now we cannot go faster. This is not every year that we change the complete representation of objects. Now it was NEEDED and we get Spur and SIsta. Stef Le 22/10/16 Ã 09:04, phil(a)highoctane.be a Ã©crit : > We need some easy to use gem-style installer on the command line. > > Pharo is perfectly usable for any kind of project provided energy is > poured in. > > Things are in flux, yes, and it is frustrating not to have it all > perfect. So what? If we weren't interested in wild things why would we > be here after all? > > Think long term: 10 years from now, improvements will have been > massively compounding (not to mention 20). > > I hope to have a huge win with Pharo business wise and be able to fund > a serious team. That's my dream. I am actively working on it. > > Pharo can stay relevant for that long I believe. I love the way it > helps me think. I love the fact that I can look everywhere I want. I > love the fact that this community has balls. I love to show the magic > we can do with it. If it all goes nowhere, I do not even mind as I > have a damn awesome time around here. > > Now, I also want a working text model. This feels like a kind of > psychological roadblock. Like a self sabotage. Let's put that dead rat > on the table and make something about it. > > I like Doru's Pillar editor. I guess the underlying engine will evolve > to make it faster. Great. Grafoscopio will also be a driving force > there I believe. Pharo can be superspeedy, no core problem. > > Sorry for the rant. > > Now back to promoting Pharo in front of Android/Angular/Java people > this afternoon at http://devfest.be (note that this is the 3rd time I > show Pharo/Amber there - they could kick me out but do not). > > /Phil > > > On Fri, Oct 21, 2016 at 8:12 PM, Dimitris Chloupis > <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > > Actually you are wrong, its not hard to use C libraries from > Pharo. UFFI is not a restart, its a continuation of Nativeboost , > they are very similar. > > Pharo FFI, whether its the old FFI, Alien, Nativeboost or UFFI, is > more or less the same. In the end an FFI is defined by C syntax , > Pharo UFFI borrows the easy of use of Nativeboost that allows you > to take c functions definition and use them as they are with a > simple copy paste. > > Pharo is also is based on very good integration with C , like > Squeak can output its code as C code via the Slang interface > though it comes with some limitations. > > The availability of C libraries to Pharo is a reflection of the > community size. Comparing with Ruby is very unfair , as Ruby is > vastly more popular (think in thousand times) , hence why you see > so many C libraries wrapped for Ruby. Of course python kicks Ruby > ass kung fu style with its vastly superior array of C wrapped > libraries. > > The moment you decide to use an unpopular language as Pharo then > if you are not prepared to get your hands dirty and you expect > things on your plate like Ruby or Python , then its time to go > back to Ruby or Python. > > Pharo is not in flux , its evolving, every new tool or library you > see is an evolution of something else. > > We dont need Gems for Pharo, Dale has done a great job with > Metacello, its easy to make a pharo project in git/github and have > it install all pharo code and built C libraries wrapped for Pharo. > Just because people are not in the habit of doing this does not > mean its not super easy to be done. For example AFAIK my project > ChronosManager was one of the first project to install from > Catalog Browser not only its Pharo code but also , pngs and audio > files. I made even an autoupdate feature that pings my github repo > to see if there are any new commits and then if so it alerts the > user and give him the ability to download the update with a single > click. All that is metacello. > > Metacello is probably one of the best if not the best package > distribution systems out there. Definetly vastly better than > Python's PyPi and Node'js NPM . I cannot praise it enough and I > have no problem criticising Pharo when I must. Dale has done an > amazing job, period. > > On the GUI front on the other hand, its messy, no doubt about it. > Morphic is huge, ugly and almost not maintained. Bloc is probably > going to be the next step. > > I think the issue here is that we dont have Arduino or Raspberry > Pi guys. Same story for my field, 3d graphics. There is a OpenGL > wrapper and the Wodden graphics engine and nothing else. I and the > author of Woden are the only people here interested into 3d > graphics, he makes Woden, I have made a bridge with Blender Python > , for using Pharo to make Blender addons and I am now in the > process of making a bridge with Unreal Engine. > > I dont see why you would have an issue using Pharo from Raspberry > Pi, we already support SDL and you can even run Pharo with no GUI > from the terminal and export any Pharo method as a command line > argument. My Python socket bridge also showed me that is dead easy > to connect Pharo with other programming languages, in my case > python , with just a few hundred lines of code. Typical IPC. > > So there are no excuses for not using Pharo, from there on, it > depends on your specific needs and wants and taste. > > On Fri, Oct 21, 2016 at 7:05 PM Todd Blanchard <tblanchard(a)mac.com > <mailto:tblanchard@mac.com>> wrote: > > >> On Oct 21, 2016, at 07:30, Norbert Hartl <norbert(a)hartl.name >> <mailto:norbert@hartl.name>> wrote: >> >> The current (!) complaint is rather based on the fact that >> everything regarding the graphics backend, widget and tools >> appears sometimes as an indefinite loop of reinventing stuff >> and improving and never get the job done. Did I mention >> 64bit, UFFI,â¦ I'm glad all these topics are worked one and I >> see a bright future if half of them are done. But then >> sometimes it looks rather dark and the light at the end of >> the tunnel just went off :) > > I feel you. > > I very much want to use Pharo to build devices from things > like Raspberry Pi's, iPhones, and Androids. I need access to > native libraries. You can't rewrite everything ever in > Smalltalk and I don't really see a good reason to. > > I've taken about ten years off from doing Smalltalk and I'm > trying to get back into it. My interest is piqued because I > want to build nice custom systems using the nifty new cheap > goodies like Arduinos and RPis and it seems tossing together a > full screen Pharo image would be a great way to build these > appliances. In that time the story for how to call out to > native code has changed...twice. Everything is broken or in > flux again. > > To me, it doesn't feel like there's any more platform to build > apps on than there was ten years ago and everything is still > "just around the corner". Pharo seem to be an experiment in > building next generation programming tools using deprecated > last generation programming tools. I don't see a lot of useful > programs being built atop it - largely because the base is > constantly shifting about. > > It is disheartening that the Ruby guys can crank out gems with > native libraries that compile and work on every platform and > pharo is still constantly half broken with loadable native > code "doable" but only with great effort. > > I looked and Moz2D doesn't seem to have a light weight build > for Raspberry Pi. Is hitching Pharo to a heavy weight > graphics library as a core requirement a good idea? > > I'm starting to think maybe we need something like Gems for > Pharo - dynamically loadable libraries and resources - > compiled at install if necessary. > >

Oct. 22, 2016

Re: [Pharo-dev] Pharo behind ALLSTOCKER marketplace

by askoh

Thank you very much for sharing. This is a great success story for Smalltalk. Hence, how did you encounter Smalltalk? How did you decide to use it instead of other popular technologies? How did you persuade management and business to follow through? You answers can help others achieve success too. All the best, Aik-Siong Koh -- View this message in context: http://forum.world.st/Pharo-behind-ALLSTOCKER-marketplace-tp4919088p4919755… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 22, 2016

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

by Dale Henrichs

Esteban, This is why I'm bringing up the idea of MetacelloProjectLoadSpec now ... my current thoughts are that MetacelloProjectLoadSpec would look like a cross between the CatalogProject, TDProjectEntry, and SCIMetacelloLoadSpec. Here are some initial examples for a ConfigurationOf and and a BaselineOf project: MetacelloProjectLoadSpec { #name : 'A4BP', #metacello : { #configuration : 'A4BP', #repository : 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main', #version : #stable, #loads : [ 'Core' ], #locked : false }, #projectUrl : 'http://a4bp.com/', #description : 'A4BP (Assessment for Business Process).\rSee more here: http://a4bp.com/', #keywords : [ 'development', 'bpmn' ], #platforms : [ #pharo ] } MetacelloProjectLoadSpec { #name : 'Tugrik', #metacello : { #baseline : 'Tugrik', #repository : 'gitfiletree://github.com/dalehenrich/Tugrik:master/repository', #onWarningLog : true, #loads : [ 'default' ], #locked : true }, #projectUrl : 'https://github.com/dalehenrich/Tugrik#tugrik', #description : 'Voyage client for GemStone', #keywords : [ 'persistence', 'voyage' ], #properties : { #tode_InstallSscript : 'project clone --https --local Tugrik', #tode_PostInstallScript : 'mount @/sys/stone/dirs/Tugrik/gsdevkit/tode /home tugrik' }, #platforms : [ #pharo, #gemstone ] } If we assume that the .ston files will be hosted directly in the github project then something like the following would be possible: 'https://raw.githubusercontent.com/GsDevKit/GsDevKit_home/gh-pages/Tugrik.st…' asMetacelloProjectLoadSpec load or: 'https://raw.githubusercontent.com/GsDevKit/GsDevKit_home/gh-pages/Tugrik.st…' metacelloLoad for sharing customized local project load specs : (FileLocator projectDirectory / 'A4BP.ston') asMetacelloProjectLoadSpec load or: (FileLocator projectDirectory / 'Tugrik.ston') metacelloLoad The above assumes that you may only want to load a project ... but if you've customized your load spec (i.e., have a local git clone that you always want used) you may just want to lock the project in your image without loading. Then you'd do something like the following: (FileLocator projectDirectory / 'A4BP.ston') asMetacelloProjectLoadSpec lock Of course a tool similar to the CatalogBrowser for local projects could be written to manage the contents of the `FileLocator projectDirectory` ... this is what the tODE project list does: project list Presumably the catalog browser could be easily converted to use MetacelloProjectLoadSpecs ... the issue of how to register a project load spec for a baseline still remains, but Pharo could accept pull requests for a github project where the user simply submits a .ston file for their project - a cross between https://github.com/GsDevKit/GsDevKit_home/tree/gh-pages and https://github.com/dalehenrich/nosql-database.org... ... just some thoughts .... Dale On 10/22/16 9:41 AM, Esteban Lorenzano wrote: > Catalog is a âtemporary solutionâ for a problem that is already 2 > years aroundâ¦ is not what I would like, and certainly is far from > perfect. > One of this days I will come with a solution that can allow baselines, > for exampleâ¦ > > Esteban > >> On 22 Oct 2016, at 18:37, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>> wrote: >> >> I'm wrong ... I hadn't followed the whole chain. Although as I've >> mentioned in another post, the Catalog is wired to ConfigurationOf >> and is Pharo-specific ... A common "project load spec" could be >> plugged into the CatalogBrowser framework and provide ConfigurationOf >> and BaselineOf support ... >> >> Dale >> >> >> On 10/22/16 8:31 AM, phil(a)highoctane.be wrote: >>> CatalogProvider projectNamed: 'QuickAccess' >>> >>> is doing that already. >>> >>> Or I am mistaken? >>> Phil >>> >>> On Sat, Oct 22, 2016 at 3:50 PM, Dale Henrichs >>> <dale.henrichs(a)gemtalksystems.com >>> <mailto:dale.henrichs@gemtalksystems.com>> wrote: >>> >>> >>> >>> On 10/22/16 3:09 AM, Esteban Lorenzano wrote: >>>> >>>>> On 22 Oct 2016, at 10:56, Dimitris Chloupis >>>>> <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >>>>> >>>>> We need some easy to use gem-style installer on the command line. >>>> >>>> we have it: >>>> >>>> ./pharo Pharo.image get Seaside3 >>>> >>>> will load seaside into your Pharo.image >>>> >>>> this is catalog based, of course (there is no magic there, if >>>> you want an easy way to install things, you need a centralised >>>> repository). >>>> >>>> Esteban >>>> >>>> ps: there are a lot of perks like that people ignoresâ¦ what we >>>> actually need is a better documentation system :) >>> Esteban, >>> >>> I really think that the catalog could benefit by a first class >>> objects like the TDProjectEntry and MetacelloProjectLoadSpec ... >>> these would be objects directly created and maintained by the >>> project developers themselves. The objects would be used for >>> custom build scripts, smalltalkCI builds, catalog loads, etc. >>> ... oh and if it was a Metacello class, it would be usable cross >>> platform (Squeak, Pharo, GemStone, etc.) >>> >>> As a coincidence, I have been planning on talking on this >>> subject at the upcoming Smalltalks conference ... The working >>> title for the talk is "Dangerous Liaisons: Smalltalk, Files and >>> Git" ... >>> >>> Dale >>> >>> >> >

Oct. 22, 2016

Re: [Pharo-dev] Again about scrolling with a trackpad

by Alexandre Bergel

Feel free to do a fix. Making Pharo usable is crucial. Personally, I have two mouses, a magic mouse when I do not do Pharo, and a old-style mouse with a physical wheel when I do Pharo. This is ridiculous. I tried in the past to remove this odd behavior, but I did not succeed. Alexandre > On Oct 21, 2016, at 11:51 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > I can understand that adding an option may be complicated, and that's why I'm asking if anyone actually need this, because otherwise we can just remove that functionality. > > Uko > > Sent from my iPhone > >> On 21 Oct 2016, at 16:47, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> This has been a problem for a very long time, it also happens with the magic mouse. >> >> It feels like there should be an option to disable interpreting side scrolling. >> >>> On 21 Oct 2016, at 16:44, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> If I remember correctly on side scrolling the vm generates "ctrl + â" and "ctrl + â" keystroke events. Then some morph listens to them and switches focus. >>> >>> Sent from my iPhone >>> >>>> On 21 Oct 2016, at 16:31, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> >>>> >>>> >>>> 2016-10-21 15:56 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: >>>> Ok, >>>> >>>> there is a problem that when you use trackpad with pharo and you scroll something strange happens. And it was documented that when you scroll sideways itâs registered as ctrl + arrow click and it switches focus. >>>> >>>> Now it seems that on Siera it became worse because now I cannot normally scroll at all. >>>> >>>> Additionally this causes a lot of problems: i.e. when someone wanted to remove history plugin from nautilus many of people protested because when your navigation is fucked up during scrolling you can get back. >>>> >>>> Now I started to think: why wonât we simply delete the code that registers these events. So I have a question, does anybody find this functionality useful? I find it super frustrating. And if everyone else does, maybe we can simply remove that. >>>> >>>> Also while the time passes, does anybody have any idea on how to hack Pharo to ignore these events? >>>> >>>> Which events? >>>> >>>> Because I need to work and I can notâ¦ >>>> >>>> Cheers. >>>> Uko >>>> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 22, 2016

Re: [Pharo-dev] Custom Pharo builds from terminal [ it was (Re: [ANN] Sparta v1.1) ]

by Esteban Lorenzano

Catalog is a âtemporary solutionâ for a problem that is already 2 years aroundâ¦ is not what I would like, and certainly is far from perfect. One of this days I will come with a solution that can allow baselines, for exampleâ¦ Esteban > On 22 Oct 2016, at 18:37, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > I'm wrong ... I hadn't followed the whole chain. Although as I've mentioned in another post, the Catalog is wired to ConfigurationOf and is Pharo-specific ... A common "project load spec" could be plugged into the CatalogBrowser framework and provide ConfigurationOf and BaselineOf support ... > > Dale > > On 10/22/16 8:31 AM, phil(a)highoctane.be <mailto:phil@highoctane.be> wrote: >> CatalogProvider projectNamed: 'QuickAccess' >> >> is doing that already. >> >> Or I am mistaken? >> Phil >> >> On Sat, Oct 22, 2016 at 3:50 PM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: >> >> >> On 10/22/16 3:09 AM, Esteban Lorenzano wrote: >>> >>>> On 22 Oct 2016, at 10:56, Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >>>> >>>> We need some easy to use gem-style installer on the command line. >>> >>> >>> we have it: >>> >>> ./pharo Pharo.image get Seaside3 >>> >>> will load seaside into your Pharo.image >>> >>> this is catalog based, of course (there is no magic there, if you want an easy way to install things, you need a centralised repository). >>> >>> Esteban >>> >>> ps: there are a lot of perks like that people ignoresâ¦ what we actually need is a better documentation system :) >> Esteban, >> >> I really think that the catalog could benefit by a first class objects like the TDProjectEntry and MetacelloProjectLoadSpec ... these would be objects directly created and maintained by the project developers themselves. The objects would be used for custom build scripts, smalltalkCI builds, catalog loads, etc. ... oh and if it was a Metacello class, it would be usable cross platform (Squeak, Pharo, GemStone, etc.) >> >> As a coincidence, I have been planning on talking on this subject at the upcoming Smalltalks conference ... The working title for the talk is "Dangerous Liaisons: Smalltalk, Files and Git" ... >> >> Dale >> >

Oct. 22, 2016