- Pharo-users - lists.pharo.org

smalltalkhub.com -> commits history

by sergio t. ruiz

i have a few projects i am playing with smalltalkhub on, but i am not sure if i am doing it right.. if i look under commits, i see no commit history, but under source, i can see about 35 different versions of the source i have committed. any ideas? thanks! -- ---- peace, sergio photographer, journalist, visionary #BitMessage BM-2D8VWUJSS41RFKh1ec83preVabHrnniExa http://www.ThoseOptimizeGuys.com http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

Feb. 12, 2014

Re: [Pharo-users] [Pharo-dev] [ANN] ScriptManager 1.7 Release for upcoming Pharo 3.0

by Sven Van Caekenberghe

Hi Torsten, On 11 Feb 2014, at 22:12, Torsten Bergmann <astares(a)gmx.de> wrote: > Thanks to Sven van Caekenberghe the ScriptManager tool hosted in project > > http://smalltalkhub.com/#!/~TorstenBergmann/ScriptManager/ > > now also provides the ability to import/export not only to a single > binary fuel file but also to a folder with readable scripts. > > This is a good idea and may also help to use external editors > or versioning systems like git or others on the custom scripts. > > I also reworked the menues to be in alignment with the common style > and polished the package for Pharo 3.0 as a new release version 1.7. > > Just open the config browser in Pharo 3.0 and load "ScriptManager". > After loading it will be available under Tools -> ScriptManager. > > Have fun > T. Thanks for including this. The only 'issue' that I had is that the line end convention used for writing the workspaces is CR (at least on my Mac), which is not cool when you want to work with the files outside the image (should be Unix style LF). Now, the File Browser does the same when creating files, as does Workspace when exporting. That is why I left it like that. BTW: I have been using your Bootstrap code all day long and it is seriously cool - I will have feedback in the coming weeks ;-) Sven

Feb. 11, 2014

[ANN] ScriptManager 1.7 Release for upcoming Pharo 3.0

by Torsten Bergmann

Thanks to Sven van Caekenberghe the ScriptManager tool hosted in project http://smalltalkhub.com/#!/~TorstenBergmann/ScriptManager/ now also provides the ability to import/export not only to a single binary fuel file but also to a folder with readable scripts. This is a good idea and may also help to use external editors or versioning systems like git or others on the custom scripts. I also reworked the menues to be in alignment with the common style and polished the package for Pharo 3.0 as a new release version 1.7. Just open the config browser in Pharo 3.0 and load "ScriptManager". After loading it will be available under Tools -> ScriptManager. Have fun T.

Feb. 11, 2014

Re: [Pharo-users] branching with monticello

by Sven Van Caekenberghe

Hi, On 11 Feb 2014, at 19:16, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Iâm worried a bit about merging. Wonât it damage some monticello meta data? If you start with 2 version with correct meta data and ancestries, no. This could be helpful: http://www.lukas-renggli.ch/blog/monticello-merging It all sounds very magic, but it is quite simple. Apart from the fact that merging often means fixing conflicts. That is true everywhere. Sven > Uko > > On 11 Feb 2014, at 18:22, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> you canâ¦ filetree is a file format. What you do with those files is up to you and your tools :) >> >> On 11 Feb 2014, at 17:30, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >>> Can we get something from git branches with file tree? >>> >>> Uko >>> >>> On 11 Feb 2014, at 17:26, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>>> in monticello, each package is itself a branch. >>>> >>>> so you can have different approachs: >>>> >>>> - you just rename your package to YourPackage-YourBranch >>>> - you use different repositories >>>> - yo do not do anything and you just realise that each package is a branch, so you can start from anywhere and merge with anything :) >>>> >>>> Esteban >>>> >>>> On 11 Feb 2014, at 16:46, sergio_101 <sergio.rrd(a)gmail.com> wrote: >>>> >>>>> i am sort of foggy on how to effectively use branching with monticello. currently, we use branches daily. we branch off the master, and give it some name "like update_user_functions".. >>>>> >>>>> we develop away on that, and when it's time, we merge that back into master, and push out to the server. >>>>> >>>>> having named branches makes it very easy for us track what's going on in the development line. >>>>> >>>>> is this possible with monticello, or am i just missing an ideology? >>>>> >>>>> thanks! >>>>> >>>>> -- >>>>> ---- >>>>> peace, >>>>> sergio >>>>> photographer, journalist, visionary >>>>> #BitMessage BM-2D8VWUJSS41RFKh1ec83preVabHrnniExa >>>>> >>>>> http://www.ThoseOptimizeGuys.com >>>>> http://www.CodingForHire.com >>>>> http://www.coffee-black.com >>>>> http://www.painlessfrugality.com >>>>> http://www.twitter.com/sergio_101 >>>>> http://www.facebook.com/sergio101 >>>> >>> >> >

Feb. 11, 2014

Re: [Pharo-users] branching with monticello

by Yuriy Tymchuk

Iâm worried a bit about merging. Wonât it damage some monticello meta data? Uko On 11 Feb 2014, at 18:22, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > you canâ¦ filetree is a file format. What you do with those files is up to you and your tools :) > > On 11 Feb 2014, at 17:30, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> Can we get something from git branches with file tree? >> >> Uko >> >> On 11 Feb 2014, at 17:26, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> in monticello, each package is itself a branch. >>> >>> so you can have different approachs: >>> >>> - you just rename your package to YourPackage-YourBranch >>> - you use different repositories >>> - yo do not do anything and you just realise that each package is a branch, so you can start from anywhere and merge with anything :) >>> >>> Esteban >>> >>> On 11 Feb 2014, at 16:46, sergio_101 <sergio.rrd(a)gmail.com> wrote: >>> >>>> i am sort of foggy on how to effectively use branching with monticello. currently, we use branches daily. we branch off the master, and give it some name "like update_user_functions".. >>>> >>>> we develop away on that, and when it's time, we merge that back into master, and push out to the server. >>>> >>>> having named branches makes it very easy for us track what's going on in the development line. >>>> >>>> is this possible with monticello, or am i just missing an ideology? >>>> >>>> thanks! >>>> >>>> -- >>>> ---- >>>> peace, >>>> sergio >>>> photographer, journalist, visionary >>>> #BitMessage BM-2D8VWUJSS41RFKh1ec83preVabHrnniExa >>>> >>>> http://www.ThoseOptimizeGuys.com >>>> http://www.CodingForHire.com >>>> http://www.coffee-black.com >>>> http://www.painlessfrugality.com >>>> http://www.twitter.com/sergio_101 >>>> http://www.facebook.com/sergio101 >>> >> >

Feb. 11, 2014

Re: [Pharo-users] branching with monticello

by Esteban Lorenzano

you canâ¦ filetree is a file format. What you do with those files is up to you and your tools :) On 11 Feb 2014, at 17:30, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Can we get something from git branches with file tree? > > Uko > > On 11 Feb 2014, at 17:26, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> in monticello, each package is itself a branch. >> >> so you can have different approachs: >> >> - you just rename your package to YourPackage-YourBranch >> - you use different repositories >> - yo do not do anything and you just realise that each package is a branch, so you can start from anywhere and merge with anything :) >> >> Esteban >> >> On 11 Feb 2014, at 16:46, sergio_101 <sergio.rrd(a)gmail.com> wrote: >> >>> i am sort of foggy on how to effectively use branching with monticello. currently, we use branches daily. we branch off the master, and give it some name "like update_user_functions".. >>> >>> we develop away on that, and when it's time, we merge that back into master, and push out to the server. >>> >>> having named branches makes it very easy for us track what's going on in the development line. >>> >>> is this possible with monticello, or am i just missing an ideology? >>> >>> thanks! >>> >>> -- >>> ---- >>> peace, >>> sergio >>> photographer, journalist, visionary >>> #BitMessage BM-2D8VWUJSS41RFKh1ec83preVabHrnniExa >>> >>> http://www.ThoseOptimizeGuys.com >>> http://www.CodingForHire.com >>> http://www.coffee-black.com >>> http://www.painlessfrugality.com >>> http://www.twitter.com/sergio_101 >>> http://www.facebook.com/sergio101 >> >

Feb. 11, 2014

Re: [Pharo-users] Xs&Os game

by ÐÐ°ÑÐºÑÑÐ½ Ð ÑÐ·ÑÐ½

Hello everyone! Happy to inform you that I've just updated my game :) There where lots of changes made due to Stef's and kilon's comments. I really appreciate your feedback. Also thanks to Phil for his note (originally this game is written on Pharo 3.0). Update: - "impossible mode is quite easy to win" -kilon. Now it is harder to win, but it is possible despite the name of mode :) - if click New Game it keeps difficulty level + playing mode(PvsP or PvsComp) + now position of it is not 0@0 - added background for game log and game state for better visibility - added the class comment: XsAndOsGame new openInWorld. - all methods now are classifyied - fixed problems reported by criticBrowser(not all problems but many) - other many minor fixes to problems which were mentioned by Stef ToDo in next versions: - make some methods shorter - divide twoPlayers logic and PlayervsComputer logic in different classes - lots of other style changes and minor fixes - AND I want to provide a possibility to play not only just on 3X3 board but on any other (but I don't know yet how to implement AI) the last point about AI should be seriously thought through and requiers some of my time:) hope to get it done Link for project: http://smalltalkhub.com/#!/~MarkRizun/XsAndOsGame/versions/XsAndOsGame-Mark… Again thanks to everyone! Mark 2014-02-10 10:22 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > I loaded the game in Pharo2.0 > > There is ImageMorph>>form: aForm missing but adding > > ImageMorph>>form: aForm > self image: aFrom > > makes it work. > > Phil > > > > > On Sun, Feb 9, 2014 at 9:59 PM, ÐÐ°ÑÐºÑÑÐ½ Ð ÑÐ·ÑÐ½ <mrizun(a)gmail.com> wrote: > >> Thanks for comment. >> I'll fix all problems and change everything you mentioned, hope to >> succeed in it. >> >> Mark >> >> >> 2014-02-09 22:51 GMT+02:00 Pharo4Stef <pharo4Stef(a)free.fr>: >> >>> Hi mark >>> >>> I read a bit your code >>> >>> It is nice for a first project!!!! >>> >>> Here are some feedback. I suggest that you take into account the easy >>> one and produce a new version and if you want to >>> train your skills you try to see how to address the difficult ones. >>> >>> Stef >>> >>> >>> >>> - Add it in the class comment >>> XsAndOsGame new openInWorld. >>> >>> - you have some unclassified protocols on the class side. >>> >>> - you may want to run smallLint (criticBorwser on your code and see the >>> hints that it can give you). >>> >>> - When you create a new game do not move the window to the top corner :) >>> >>> easyBtn -> easyButton (you do not pay per character :)) >>> >>> findEmptyCellPos -> findEmptyCellPosition >>> not in accessing >>> >>> impBtn -> impossibleButton >>> >>> .... :) >>> - Why do you need a separate class just for three colors? >>> I would merge >>> XsAndOsGameColors and XsAndOsGame >>> >>> XsAndOsGame>>initialize is long >>> May be you should extract some methods from it (methods that you can >>> then reuse for other tasks) >>> >>> >>> renderOContents >>> | delta offset x1 y1 x2 y2 rect | >>> delta := CellRenderer cellExtent - 1. >>> offset := self offsetWithinGridForm. >>> x1 := offset x + self oCorner x. >>> x2 := offset x + delta x - self oCorner x. >>> y1 := offset y + self oCorner y. >>> y2 := offset y + delta y - self oCorner y. >>> rect := Rectangle new setOrigin: x1 @ y1 corner: x2 @ y2. >>> self targetForm getCanvas >>> fillOval: rect >>> color: XsAndOsGameColors gameBoardBackgroundColor >>> borderWidth: 3 >>> borderColor: XsAndOsGameColors OColor >>> >>> What do you refer to CellRenderer direcly? self class ? >>> >>> >>> rendererFor: aCell >>> "VERY BAD IMPLEMENTATION OF THIS METHOD!!!" >>> >>> aCell class = EmptyCell >>> ifTrue: [ ^ CellRenderer ]. >>> aCell class = XCell >>> ifTrue: [ ^ XCellRenderer ]. >>> aCell class = OCell >>> ifTrue: [ ^ OCellRenderer ] >>> >>> indeed :) >>> why not implementing some methods call renderClass and sending a message >>> to the object :) >>> >>> mptyCell>>initialize >>> super initialize. >>> >>> >>> >>> CellRenderer>>offsetWithinGridForm >>> "Returns a point - left top corner of current cell" >>> >>> ^ CellRenderer cellExtent * ((self cellLocation x - 1) @ (self >>> cellLocation y - 1)) >>> => self clas cellExtent >>> >>> CellRenderer >> renderBorderBottom >>> | delta offset x1 y1 x2 y2 | >>> delta := CellRenderer cellExtent - 1. >>> offset := self offsetWithinGridForm. >>> x1 := offset x. >>> x2 := x1 + delta x. >>> y1 := offset y + delta y. >>> y2 := y1. >>> self targetForm getCanvas >>> line: x1 @ y1 >>> to: x2 @ y2 >>> width: 1 >>> color: XsAndOsGameColors cellBorderColor >>> >>> => >>> CellRenderer >> renderBorderBottom >>> | delta offset x1 y1 x2 y2 | >>> delta := self class cellExtent - 1. >>> offset := self offsetWithinGridForm. >>> x1 := offset x. >>> x2 := x1 + delta x. >>> y1 := offset y + delta y. >>> y2 := y1. >>> self targetForm getCanvas >>> line: x1 @ y1 >>> to: x2 @ y2 >>> width: 1 >>> color: XsAndOsGameColors cellBorderColor >>> >>> >>> I was wondering why you need Grid (I would rename it CellGrid) and do >>> not use a Matrix. >>> >>> grid sizeOfGrid >>> -> I would rename sizeOfGrid into size like that your grid can be a >>> bit more polymorphic from its API point of view >>> >>> >>> makeGameBoarMorph >>> -> typo :) >>> Now I want wondering why you do not have an instance variable to hold it >>> >>> >>> Future fun ideas for new versions: >>> -------------------------------------------- >>> playerVsComputer >>> self vsComputer >>> ifTrue: [ >>> self vsComputer: false. >>> self stateMorph contents: 'Player 1 VS Player 2' ] >>> ifFalse: [ >>> self vsComputer: true. >>> self stateMorph contents: 'Player VS Computer ---> Difficulty: ' , self >>> difficulty asString ]. >>> self vsComputer >>> ifTrue: [ >>> self easyBtn enable. >>> self normalBtn enable. >>> self impBtn enable ] >>> ifFalse: [ >>> self easyBtn disable. >>> self normalBtn disable. >>> self impBtn disable ] >>> This kind of code may be think that may be you need another object that >>> represent the >>> TwoUsers >>> vsComputer >>> strategy >>> I'm not sure but clicked look quite long. >>> May be you should create another class that can represent the logic of >>> the game. >>> >>> A really interesting exercise would be to see how you can create a >>> boardGame for 15*15 and see how it breaks some hidden rules. >>> On 08 Feb 2014, at 15:07, ÐÐ°ÑÐºÑÑÐ½ Ð ÑÐ·ÑÐ½ <mrizun(a)gmail.com> wrote: >>> >>> Updated XsAndOsGame: added AI, also fixed some problems, that Damien >>> mentioned in his comments. >>> Btw, thanks to Damien, because I learned for myself a lot of new useful >>> things. >>> Note: The new version is XsAndOsGame (NOT Xs&OsGame) ! >>> To play it type in workspace: XsAndOsGame new openInWorld. >>> If you want to play vs computer press button "ToggleMode" and choose >>> difficulty. Initially it is easy. >>> >>> Mark >>> >>> >>> 2014-02-05 15:57 GMT+02:00 ÐÐ°ÑÐºÑÑÐ½ Ð ÑÐ·ÑÐ½ <mrizun(a)gmail.com>: >>> >>>> Thanks, I'll certainly take a look at it >>>> >>>> >>>> 2014-02-05 Damien Cassou <damien.cassou(a)gmail.com>: >>>> >>>> On Tue, Feb 4, 2014 at 8:58 PM, ÐÐ°ÑÐºÑÑÐ½ Ð ÑÐ·ÑÐ½ <mrizun(a)gmail.com> wrote: >>>>> > I should think how to write this tutorial. >>>>> >>>>> >>>>> on the technical point of view, I advise you to use Pillar: >>>>> http://www.smalltalkhub.com/#!/~Pier/Pillar >>>>> >>>>> -- >>>>> Damien Cassou >>>>> http://damiencassou.seasidehosting.st >>>>> >>>>> "Success is the ability to go from one failure to another without >>>>> losing enthusiasm." >>>>> Winston Churchill >>>>> >>>>> >>>> >>> >>> >> >

Feb. 11, 2014

Re: [Pharo-users] Using/editing external packages..

by sergio_101

i think you're right.. i just need to sit down and walk myself through it with this codebase.. since i am the maintainer of the codebase in question (although i did not write it), i really want to address this issue correctly, and not cut any corners.. thanks! On Tue, Feb 11, 2014 at 11:20 AM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > sergio_101 wrote > > i am currenty develop an app in seaside, and am wondering about best > > practices when using external packages. > > I've found the easiest and most flexible approach is two-fold: > - Refactor the underlying library with the hooks and abstractions you need > - And then, subclass > > If you just override and monkey-patch, I feel you are more vulnerable to > the > library changing underneath you, as well is potentially making your code > harder to understand. If you can make the library designed to use it the > way > you want, you will reduce duplication and the chance of someone else coming > in and doing it in an incompatible way, as well as give the library > maintainers an idea of what you're doing, so they may consider that in > making non-backward-compatible changes. > > Of course, that's ideal and requires library maintainers open to accepting > such changes, but in practice I've found this to be true (with Pharo, > Magritte, BabyMock...) > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Using-editing-external-packages-tp4742801p4742832.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > -- ---- peace, sergio photographer, journalist, visionary #BitMessage BM-2D8VWUJSS41RFKh1ec83preVabHrnniExa http://www.ThoseOptimizeGuys.com http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

Feb. 11, 2014

Re: [Pharo-users] branching with monticello

by Yuriy Tymchuk

Can we get something from git branches with file tree? Uko On 11 Feb 2014, at 17:26, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > in monticello, each package is itself a branch. > > so you can have different approachs: > > - you just rename your package to YourPackage-YourBranch > - you use different repositories > - yo do not do anything and you just realise that each package is a branch, so you can start from anywhere and merge with anything :) > > Esteban > > On 11 Feb 2014, at 16:46, sergio_101 <sergio.rrd(a)gmail.com> wrote: > >> i am sort of foggy on how to effectively use branching with monticello. currently, we use branches daily. we branch off the master, and give it some name "like update_user_functions".. >> >> we develop away on that, and when it's time, we merge that back into master, and push out to the server. >> >> having named branches makes it very easy for us track what's going on in the development line. >> >> is this possible with monticello, or am i just missing an ideology? >> >> thanks! >> >> -- >> ---- >> peace, >> sergio >> photographer, journalist, visionary >> #BitMessage BM-2D8VWUJSS41RFKh1ec83preVabHrnniExa >> >> http://www.ThoseOptimizeGuys.com >> http://www.CodingForHire.com >> http://www.coffee-black.com >> http://www.painlessfrugality.com >> http://www.twitter.com/sergio_101 >> http://www.facebook.com/sergio101 >

Feb. 11, 2014

Re: [Pharo-users] branching with monticello

by Esteban Lorenzano

in monticello, each package is itself a branch. so you can have different approachs: - you just rename your package to YourPackage-YourBranch - you use different repositories - yo do not do anything and you just realise that each package is a branch, so you can start from anywhere and merge with anything :) Esteban On 11 Feb 2014, at 16:46, sergio_101 <sergio.rrd(a)gmail.com> wrote: > i am sort of foggy on how to effectively use branching with monticello. currently, we use branches daily. we branch off the master, and give it some name "like update_user_functions".. > > we develop away on that, and when it's time, we merge that back into master, and push out to the server. > > having named branches makes it very easy for us track what's going on in the development line. > > is this possible with monticello, or am i just missing an ideology? > > thanks! > > -- > ---- > peace, > sergio > photographer, journalist, visionary > #BitMessage BM-2D8VWUJSS41RFKh1ec83preVabHrnniExa > > http://www.ThoseOptimizeGuys.com > http://www.CodingForHire.com > http://www.coffee-black.com > http://www.painlessfrugality.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101

Feb. 11, 2014