- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-users] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by Guido Stepken

Should be very easy to introduce reference pointers towards a number of additional images.... Am 03.11.2011 um 13:05 schrieb Norbert Hartl <norbert(a)hartl.name>: > > Am 03.11.2011 um 12:57 schrieb Guido Stepken: > >> I always thought, the IMAGE *is* already an OO database!?? >> > Yes, it is an OO database with a restriction in the size of your volatile memory (unless you use GemStone or LOOM) > > Norbert > >> Guido Stepken >> >> Am 02.11.2011 um 15:27 schrieb Igor Stasenko <siguctua(a)gmail.com>: >> >>> How about new source code management? >>> >>> In terms of: >>> - better abstraction of source code access in image >>> - create a shared repository (database) , which can be used to browse >>> the history of all source code of Pharo and its predecessor up to >>> Squeak 1.0. >>> >>> We are discussed this idea couple times, and we already having some >>> pieces of puzzle , like Ring. >>> Also, there is already a project made by someone (forgot the name) , >>> who already storing all source code in database and managing it there. >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > >

Nov. 3, 2011

Re: [Pharo-project] [Pharo-users] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by Norbert Hartl

Am 03.11.2011 um 12:57 schrieb Guido Stepken: > I always thought, the IMAGE *is* already an OO database!?? > Yes, it is an OO database with a restriction in the size of your volatile memory (unless you use GemStone or LOOM) Norbert > Guido Stepken > > Am 02.11.2011 um 15:27 schrieb Igor Stasenko <siguctua(a)gmail.com>: > >> How about new source code management? >> >> In terms of: >> - better abstraction of source code access in image >> - create a shared repository (database) , which can be used to browse >> the history of all source code of Pharo and its predecessor up to >> Squeak 1.0. >> >> We are discussed this idea couple times, and we already having some >> pieces of puzzle , like Ring. >> Also, there is already a project made by someone (forgot the name) , >> who already storing all source code in database and managing it there. >> >> -- >> Best regards, >> Igor Stasenko. >> >

Nov. 3, 2011

Re: [Pharo-project] [Pharo-users] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by Guido Stepken

I always thought, the IMAGE *is* already an OO database!?? Guido Stepken Am 02.11.2011 um 15:27 schrieb Igor Stasenko <siguctua(a)gmail.com>: > How about new source code management? > > In terms of: > - better abstraction of source code access in image > - create a shared repository (database) , which can be used to browse > the history of all source code of Pharo and its predecessor up to > Squeak 1.0. > > We are discussed this idea couple times, and we already having some > pieces of puzzle , like Ring. > Also, there is already a project made by someone (forgot the name) , > who already storing all source code in database and managing it there. > > -- > Best regards, > Igor Stasenko. >

Nov. 3, 2011

Re: [Pharo-project] [Pharo-users] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by StÃ©phane Ducasse

Yes but now I was more thinking about what is urgent to get done. Stef > How about new source code management? > > In terms of: > - better abstraction of source code access in image > - create a shared repository (database) , which can be used to browse > the history of all source code of Pharo and its predecessor up to > Squeak 1.0. > > We are discussed this idea couple times, and we already having some > pieces of puzzle , like Ring. > Also, there is already a project made by someone (forgot the name) , > who already storing all source code in database and managing it there. > > -- > Best regards, > Igor Stasenko. >

Nov. 3, 2011

Re: [Pharo-project] Moving a file

by StÃ©phane Ducasse

we should add it. Stef On Nov 3, 2011, at 2:09 AM, Sean P. DeNigris wrote: > Neither the Squeak file system support, nor FS seem to contain logic to move > a file, like Unix's mv command. This seems like a basic piece of > functionality. Why is it missing? > > Thanks. > Sean > > -- > View this message in context: http://forum.world.st/Moving-a-file-tp3983916p3983916.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 3, 2011

Re: [Pharo-project] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by StÃ©phane Ducasse

excellent news > - Once again... I would LOVE to have a really working-out-of-the-box multithreaded FFI with callbacks. > > and for me to finish my part of this (the VM implementation and Alien support) I need review of my VM code. Since Cadence want this too I should be in a position to spend considerable time on it in a few weeks. > > This is a MUST if Pharo wants to be business friendly. > > I couldn't agree more. A platform must have an excellent FFI to be useful. >

Nov. 3, 2011

Re: [Pharo-project] [Pharo-users] Brainstorming on the roadmap for first Pharo Consortium Engineer :)

by StÃ©phane Ducasse

Yes this is a long overdue. We will start another pass on it with nick in a week. So we will see: we want to have all the compilation chain to work in an environment. Stef > >> Now the free items with probably igor involvement >> - Multiwindowing support >> - Fully working multithreaded FFI with ***Documentation*** >> - Filesystem fix and integration >> - Integration of OPAL >> - RPackage integration > > I like to add environments so we can have multiple versions in the same image and get rid of default global state. I think you have that already on your mind even with separate object memories. > > Norbert >

Nov. 3, 2011

Re: [Pharo-project] Comment Syntax

by Milan Mimica

And while at it, make it right and allow nesting. Please. On 3 November 2011 08:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > to me "* *" convey much better that this is a comment. > > Stef > > On Nov 1, 2011, at 6:08 PM, Eliot Miranda wrote: > > > > > > > On Mon, Oct 31, 2011 at 2:22 PM, Lukas Renggli <renggli(a)gmail.com> > wrote: > > The problem is that both #/* and #/* are valid binary operators, so > > they don't work well for comments. > > > > I don't really remember what I proposed a few years ago, although I > > remember that exactly the same proposal was made. What would work is > > to use something like "* and *" (or any other double thing that starts > > with a double quote). Like this the comments could contain double > > quotes. > > > > Gilad Bracha chose (* & *) for Newspeak. These are not valid binary > selectors and * can't follow ( in valid code. A good choice. > > > > > > As a short term solution you can also put your comments into single > > quotes. Unused string literals are removed by the compiler. > > > > Lukas > > > > On 31 October 2011 22:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > Me too. > > > > > > Sean lukas proposed a syntax for that in the mailing-list a year ago. > > > If you find it please resent it. > > > > > > Stef > > > > > > On Oct 31, 2011, at 9:12 PM, Sean P. DeNigris wrote: > > > > > >> Would it be difficult/valuable to create an alternate comment syntax? > I often > > >> find myself wanting to comment a large block itself containing > comments. It > > >> would be nice to have something like C++'s /* */. I feel like this > may have > > >> been brought up before, but couldn't find it searching the lists. > > >> > > >> Sean > > >> > > >> -- > > >> View this message in context: > http://forum.world.st/Comment-Syntax-tp3961451p3961451.html > > >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > >> > > > > > > > > > > > > > > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > > > > > > > -- > > best, > > Eliot > > > > > -- Milan Mimica http://sparklet.sf.net

Nov. 3, 2011

Re: [Pharo-project] Comment Syntax

by StÃ©phane Ducasse

to me "* *" convey much better that this is a comment. Stef On Nov 1, 2011, at 6:08 PM, Eliot Miranda wrote: > > > On Mon, Oct 31, 2011 at 2:22 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > The problem is that both #/* and #/* are valid binary operators, so > they don't work well for comments. > > I don't really remember what I proposed a few years ago, although I > remember that exactly the same proposal was made. What would work is > to use something like "* and *" (or any other double thing that starts > with a double quote). Like this the comments could contain double > quotes. > > Gilad Bracha chose (* & *) for Newspeak. These are not valid binary selectors and * can't follow ( in valid code. A good choice. > > > As a short term solution you can also put your comments into single > quotes. Unused string literals are removed by the compiler. > > Lukas > > On 31 October 2011 22:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Me too. > > > > Sean lukas proposed a syntax for that in the mailing-list a year ago. > > If you find it please resent it. > > > > Stef > > > > On Oct 31, 2011, at 9:12 PM, Sean P. DeNigris wrote: > > > >> Would it be difficult/valuable to create an alternate comment syntax? I often > >> find myself wanting to comment a large block itself containing comments. It > >> would be nice to have something like C++'s /* */. I feel like this may have > >> been brought up before, but couldn't find it searching the lists. > >> > >> Sean > >> > >> -- > >> View this message in context: http://forum.world.st/Comment-Syntax-tp3961451p3961451.html > >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >> > > > > > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > > > > -- > best, > Eliot >

Nov. 3, 2011

Re: [Pharo-project] Issue tracker states

by StÃ©phane Ducasse

How do you review code in squeak? Because we could have another stream and push between one and the other. I mean practically? But this is because that the package arrives in MCBrowser that you read it? How do you deal with changes requiring a lot of changes in multiple packages? How do you know that they all work together? Now I often have to fix some more changes when I integrate fixes because it happens that people forget a detail there and there. Stef > Hi, >> >> We started to improve the states defined in the tracker... this now has: >> >> >> FixToInclude = QA has verified that the fix worked, needs to be integrated >> FixReviewNeeded = Code is there, but a review is needed >> NoSourcesAvailable = fix proposed, but machine readable code missing >> Workneeded = Next action is defined but not yet completed >> NextActionNeeded = What is the next action? >> Accepted = Problem reproduced / Need acknowledged >> New = Nobody looked at this yet >> OnHold = We will come back later to this issue, no action possible now >> >> >> The issue tracker by default sorts the items to show the ones on top that have progressed >> the most: >> >> http://code.google.com/p/pharo/issues/list >> >> >> The idea is that the "FixToInclude" status should be integrated very quickly (within a day), >> later maybe even automatically. >> >> Marcus >> > > I think this is a good pragmatic list. > > One thing I wonder is whether we can mark our own fix as "FixToInclude" > In theory, we should not because we are bypassing a peer review. > We should not lower quality insurance. > But practically it depends on two things: > - the level of work supported by integrators > - whether you have enough peer reviewers > and how easy or involving is such a review (the reviewer throughput) > > I suppose Marcus would like to be replaced by an automaton and reduce > integrator support. > It shall then be mandatory to tag our own fixes as "FixReviewNeeded". > But if ever you don't have enough reviewer throughput, then the > "FixReviewNeeded" will start accumulating in the tracker. > > If we fail to increase the throughput (with an army of reviewers or > some facilitating tools) then Marcus (and Stef) burden won't lighten. > > I repeat once again, but I prefer the squeak-trunk smooth process were > the changes are published in a mailing list. > They CAN BE reviewed more easily, and I'm sure they ARE reviewed more > efficiently than in Pharo process (I mean by many more eyes). > As a committer, I can then publish directly in trunk without the inbox stage. > It's very like a direct "FixToInclude" > But that does not mean there will be no review. > But maybe I'm tainted ;) > > Nicolas > >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> >

Nov. 3, 2011