- Pharo-users - lists.pharo.org

Re: [Pharo-users] Linux and Windows 3.0 differences

by phil＠highoctane.be

On Wed, Mar 4, 2015 at 1:17 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sebastian Heidbrink-2 wrote >> I just returned from a one on one Smalltalk introduction I gave tonight. > > Cool!! > > > Sebastian Heidbrink-2 wrote >> Date fromString: method >> contains a method comment on Windows and on Ubuntu it doesn't even >> include an implementation. > > Could you give more details about this? #fromString: contains no VM > primitives and so should be bit identical on all platforms. > > > Sebastian Heidbrink-2 wrote >> copy&paste from Chrome to Pharo 4.0 workspace/Playground on Ubuntu did >> not work either. Beware, sometimes it is a Chrome problem, not a Pharo one. > > IIRC this is a well-known problem with no solution yet :/ > > > Sebastian Heidbrink-2 wrote >> Tonight we setup pharo-launcher and two images.... 5 minutes later: >> "Wow,... that was fast! And we can start now?" >> :-D > > Yes, a /lot/ of work has gone into cleaning, simplifying, redesigning. > Thanks for the encouragement :) > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Linux-and-Windows-3-0-differences-tp4809369p4809414.h… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > -- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

March 4, 2015

Re: [Pharo-users] Some MongoTalk cleanups

by phil＠highoctane.be

On Wed, Mar 4, 2015 at 1:04 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Phil wrote: >>Is it in 3.0 repo too? > > No, even when you copy it the #stable for 3.0 points to the old one > because I do not work with such an outdated Pharo version ;) Well, should work anyway, I'll dump a copy in my own repo and work from there. The best part of what you mentioned are the docs. While we are at it, one thing that I see of value is to have a pool that would be implemented in MongoTalk and not in all projects. e.g. VoyageMongo has a pool and MaplessMongo has another implementation (obviously incompatible). I'd love to see the VOMongoPool go into the MongoTalk and become a MongoPool. This is needed anyway. Thanks for taking the time to write comments, we should at one point write a chapter about MongoTalk as it is not that clear on how one does special things (mailing lists work for me but it takes longer than read a chapter). As I am going to spend a month on Mongo related stuff, I hope to be able to write a couple of things about that. > > You can try out and adopt to your needs, I use Pharo 4 already. In production? With a ton of configurations loaded? Wow. Just not working for me I am afraid. Pharo3.0 is the released version. Pharo4.0 is a moving target. Phil > > Norbert wrote: >> are the *-Tests-* package for compatibility reasons for pharo 2? Otherwise they should be called *-Tests, right? > > No, I just follow the regular naming convention of Seaside packages here that once was also agreed to > use for Pharo as well: https://code.google.com/p/seaside/wiki/PackageNaming > > It is used by Pharo (not on all places yet) and most projects (Glamour, GT, Seaside, Bootstrap, Artefact, ... YouNameIt) and > MongoTalk should follow as well. > > Bye > T. > >

March 4, 2015

Re: [Pharo-users] Some MongoTalk cleanups

by Norbert Hartl

> Am 04.03.2015 um 13:04 schrieb Torsten Bergmann <astares(a)gmx.de>: > > Phil wrote: >> Is it in 3.0 repo too? > > No, even when you copy it the #stable for 3.0 points to the old one > because I do not work with such an outdated Pharo version ;) > > You can try out and adopt to your needs, I use Pharo 4 already. > > Norbert wrote: >> are the *-Tests-* package for compatibility reasons for pharo 2? Otherwise they should be called *-Tests, right? > > No, I just follow the regular naming convention of Seaside packages here that once was also agreed to > use for Pharo as well: https://code.google.com/p/seaside/wiki/PackageNaming > > It is used by Pharo (not on all places yet) and most projects (Glamour, GT, Seaside, Bootstrap, Artefact, ... YouNameIt) and > MongoTalk should follow as well. That is because monticello deals packages based on substring match. Should IMHO be changed in the not so far future. Norbert

March 4, 2015

Re: [Pharo-users] Linux and Windows 3.0 differences

by Sean P. DeNigris

Sebastian Heidbrink-2 wrote > I just returned from a one on one Smalltalk introduction I gave tonight. Cool!! Sebastian Heidbrink-2 wrote > Date fromString: method > contains a method comment on Windows and on Ubuntu it doesn't even > include an implementation. Could you give more details about this? #fromString: contains no VM primitives and so should be bit identical on all platforms. Sebastian Heidbrink-2 wrote > copy&paste from Chrome to Pharo 4.0 workspace/Playground on Ubuntu did > not work either. IIRC this is a well-known problem with no solution yet :/ Sebastian Heidbrink-2 wrote > Tonight we setup pharo-launcher and two images.... 5 minutes later: > "Wow,... that was fast! And we can start now?" > :-D Yes, a /lot/ of work has gone into cleaning, simplifying, redesigning. Thanks for the encouragement :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Linux-and-Windows-3-0-differences-tp4809369p4809414.h… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 4, 2015

Re: [Pharo-users] Some MongoTalk cleanups

by Torsten Bergmann

Phil wrote: >Is it in 3.0 repo too? No, even when you copy it the #stable for 3.0 points to the old one because I do not work with such an outdated Pharo version ;) You can try out and adopt to your needs, I use Pharo 4 already. Norbert wrote: > are the *-Tests-* package for compatibility reasons for pharo 2? Otherwise they should be called *-Tests, right? No, I just follow the regular naming convention of Seaside packages here that once was also agreed to use for Pharo as well: https://code.google.com/p/seaside/wiki/PackageNaming It is used by Pharo (not on all places yet) and most projects (Glamour, GT, Seaside, Bootstrap, Artefact, ... YouNameIt) and MongoTalk should follow as well. Bye T.

March 4, 2015

Re: [Pharo-users] Some MongoTalk cleanups

by Norbert Hartl

Thanks Torsten, are the *-Tests-* package for compatibility reasons for pharo 2? Otherwise they should be called *-Tests, right? Norbert > Am 04.03.2015 um 11:25 schrieb Torsten Bergmann <astares(a)gmx.de>: > > Hi, > > cleaned up MongoTalk a little bit: > > - added a new baseline 1.7 with separate test packages for "BSON" and "Core", so tests are now separately loadable > - more comments and more/better categorizations > - printOn: in database and collections to print the name > - MongoQueries is now "Mongo-Queries" and "Mongo-Tests-Queries" (hence the name of the first to be in > alignment with other packages) > - make Config aware/loadable for upcoming Pharo 4 > - the Config now is working and saved with Versionner > - the Config also includes groups (Core, Tests and default) > - it is now available in MetaRepoForPharo40 so it is in the config browser of Pharo4 > - all 55 tests are green in latest Pharo 4.0 #40534 > > Just cleanups, no behavior changes > > Bye > T. > <mongotalk.png>

March 4, 2015

Re: [Pharo-users] Some MongoTalk cleanups

by phil＠highoctane.be

Is it in 3.0 repo too? Le 4 mars 2015 11:25, "Torsten Bergmann" <astares(a)gmx.de> a Ã©crit : > Hi, > > cleaned up MongoTalk a little bit: > > - added a new baseline 1.7 with separate test packages for "BSON" and > "Core", so tests are now separately loadable > - more comments and more/better categorizations > - printOn: in database and collections to print the name > - MongoQueries is now "Mongo-Queries" and "Mongo-Tests-Queries" (hence the > name of the first to be in > alignment with other packages) > - make Config aware/loadable for upcoming Pharo 4 > - the Config now is working and saved with Versionner > - the Config also includes groups (Core, Tests and default) > - it is now available in MetaRepoForPharo40 so it is in the config browser > of Pharo4 > - all 55 tests are green in latest Pharo 4.0 #40534 > > Just cleanups, no behavior changes > > Bye > T. >

March 4, 2015

Some MongoTalk cleanups

by Torsten Bergmann

Hi, cleaned up MongoTalk a little bit: - added a new baseline 1.7 with separate test packages for "BSON" and "Core", so tests are now separately loadable - more comments and more/better categorizations - printOn: in database and collections to print the name - MongoQueries is now "Mongo-Queries" and "Mongo-Tests-Queries" (hence the name of the first to be in alignment with other packages) - make Config aware/loadable for upcoming Pharo 4 - the Config now is working and saved with Versionner - the Config also includes groups (Core, Tests and default) - it is now available in MetaRepoForPharo40 so it is in the config browser of Pharo4 - all 55 tests are green in latest Pharo 4.0 #40534 Just cleanups, no behavior changes Bye T.

March 4, 2015

Native language support

by Nick Doodka

Hi all. I would like to use Pharo in my native language (Ukrainian in my case or Cyrillic), but I cannot enter some capital letters to Workspace / System Browser because it's fails on letters: CapsLock or Shift+<Keys> -> [~YGJK"V]. That behavior take place only in Pharo ver. 3 and 4. In Pharo 2.0 all keys working good! What is wrong? Platform - Windows XP

March 4, 2015

Re: [Pharo-users] Git refreshing

by Thierry Goubier

2015-03-03 23:38 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Well, as you have noticed in Java, C or C++, switching branches does >>> not call make automatically :) >>> >>> You can use git hooks for that. >>> >> >> Ok. Then I would suggest you take the code source of CLANG, LLVM, >> OpenOffice or of the Linux kernel, you add the git hooks to call make, and >> you admire how fast changing branches becomes ;) > > Sure; large project would take long regardless but comparatively small > (~10kloc) project would get checkouted fast, also it doesn't just > completely rewrite the filesystem, but only the actual changes (which is > for my use cases most of the time in the order of tens of files) > As GitFileTree stands, some things are easy to do; others could be added. Note that: GitFileTree makes it easy to browse a specific commit without touching or branching or checking out the repository. > > >> Want to switch branches before committing? Can do. >> > How? :-o If I switch the branch from git (command line) then there is > disparity. > Well, yes and no. What you are working on is stashed inside your image (your current working copy). That you change, branch or checkout the underlying git repository doesn't matter. On a refresh or the repository inspector, GitFileTree will pick all the changes without any perturbation on your working copy. You have to understand that Monticello coupling of a package with a repository is very loose. Each time you do something with Monticello, it won't go straight for the repository the package came from, but instead will scan all repositories if they have something relevant. I'll try to rephrase, maybe it'll be clearer. Your working copy in the Pharo image (the modified package you are working on) is, to take a git concept, your staging area / changes to head. If you checkout / change branch / pull the git repository, you make the equivalent of stash, git checkout, and recreate your changes on top of the new HEAD (not exactly like that, but this is how GitFileTree will map your changes to git). By the way, for FileTree users: FileTree does the same thing... but with next to zero control over the git status. > > I'm not a git expert, but I know enough about git (and git users:)) that >> each and everyone may have its opinion on the way git should be used, and, >> as such, I've decided on GitFileTree that I wouldn't claim to hold the way >> it should be used(tm). > > Yes, I need to think about myself a bit... I am used to certain workflow > and I guess I was greedy with wanting everything. > Maybe also I'm not very clear about the interaction between Monticello and Git. > > >> I will have to think about it. I am used to my git workflow and now I am >>> kind of lost how to use it properly from Pharo; since I am cut off from >>> git. One idea that is crossing my mind is having synchronized filedumps >>> (filetree) in a folder and not worry about git or monticello inside >>> Pharo at all. (And when I change code outside it would magically change >>> also inside). >>> >> >> Please explore the idea; just try to focus on that: >> > Adding it my (endless) todolist, I would need to learn a bit (=lot) about > monticello first and how these things actually work inside Pharo so it > could be done, but just like everybody I have a lot on my plate. (And I > have also tend to eat more than I can chew.) > I would say, probably not that much about Monticello. But it could be nice if we make the minimum a bit clearer, such as documenting a few entry points (load a package, save a package, list all dirty packages, etc...) What we need more, is things along the lines of: - If I do operation A in my git repository, I want my image Monticello to do X - If I do operation B in Monticello, I want my git repository to do the operation Y Once we have a list like that, we can: add ways to trigger X when A was done (or add a button in Pharo to do A, followed by X), and, when doing B in MC, have GitFileTree do Y. > >> At the same time, there is just me and Max (and Esteban as well, I think) >> working on getting that git support working, so don't bash us too much. >> It's hard enough to get it done (look at Max questions about libcgit) that >> we don't need too much additional pressure. > > I am really sorry if my message sounded harsh, I in no way intended > something like that. Sometimes I am more greedy and picky about software > than I should be. I'll add some positive emoticons next time so it will be > more happy. :) > > I am grateful for the work you have done, after all I do like it and I am > happy I was able to make the switch to git, despite me missing features; so > please don't my ramblings as bashing, they were intended (albeit bit > directly) only as questions/ideas. > If I can convince you to help me, then that will be great :) Thierry

March 4, 2015