- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Misc. newbie questions

by Nicolas Cellier

2012/1/6 Lukas Renggli <renggli(a)gmail.com>: > On 6 January 2012 11:20, Peter Hugosson-Miller <oldmanlink(a)gmail.com> wrote: >> On 6 jan 2012, at 06:41, "Gerry Weaver" <gerryw(a)compvia.com> wrote: >> >> 2. There appear to be some tool choices in the Pharo image. I would like to >> be able to create a class and it's methods in an editor in one go. I like >> being able to see all of the class code at once. Is there a way to do this? >> Â I just want to be able to type it all in and accept (evaluate?) all at >> once. >> >> This is an interesting question to me personally. After 15 years of working >> exclusively in Smalltalk I've recently been forced to start programming in >> Java, where the source code is always (as far as I know) arranged in the way >> you describe. >> >> This organization just emphasizes the dead and compiled nature of Java (and >> similar languages), compared to the living objects of Smalltalk, where even >> methods are objects, created by sending messages to other objects. Source >> code is relegated to being a mere artifact, which can be saved and organized >> in any way one wishes, and preferably never shows its ugly face to the coder >> :-p > > Which of course is no argument why Smalltalk code could not be > displayed in a more programmer friendly way as a continuous block of > text. There is no technical reason why source ranges in text box > couldn't correspond to life method objects. Compared to other > languages it is extremely tedious in Smalltalk to get an overview over > a project, a package, or even a single class or to navigate between > entities. > >> And yes, I really *really* miss a good, object oriented class browser! > > Eclipse is pretty good, especially with the Java Browsing Perspective. > > Lukas > As soon as you would display the code for many methods in a single text pane, you will find file-based-educated people making large refactorings in a single pass... Imagine this leads to many syntax errors, they will soon be willing to save their changes for a later rework... This would be a complete change in programming flow and if we really want to support this, we would have to: - add a way to save syntactically incorrect code - let IDE tools work on partially correct code (syntax highlighting, navigation, etc...) IMHO, these features add a lot of complexity... Is it really worth? I like the discipline of focusing on a single method until it is at least syntactically correct. On the other hand, in Smalltalk we have to transfer the complexity of multi-method changes in the refactoring engines/menus when some simple modify/replace in a file would work. Nicolas > -- > Lukas Renggli > www.lukas-renggli.ch >

Jan. 7, 2012

Re: [Pharo-project] Bug in FileSystem

by Sven Van Caekenberghe

On 07 Jan 2012, at 14:19, Henrik Sperre Johansen wrote: > 1) There's no next: into: (which returns the amount read). It's really the only way to do buffers without garbage allocations. The 2 key methods for efficient IO are: readInto: collection startingAt: offset count: requestedCount "Read requestedCount elements into collection starting at offset, returning the number of elements read, there could be less elements available." next: count putAll: collection startingAt: offset "Write count bytes from collection starting at offset." All other bulk operations can be written in terms of these (see for example Zodiac streams). Sven

Jan. 7, 2012

Re: [Pharo-project] Pharo by Example

by Michael Roberts

It is hopefully explained somewhere in a book.... It is more complex than needed by history. Here is what I roughly understand: Categories are the original mechanism to group classes together. The browser shows this as the left most pane and there are tools to allow you to reorganise it as you want. The category is just a string associated with the class (or the class' organiser). All code originally lived in the ST80 (or early squeak) image. You could move it around externally by filing it out either into a .st file or change set .cs file. Class and method definitions in this chunk format are quite flexible and specify the changes that should be made on file-in. You are not constrained to move whole classes or whole class categories around. The history of Smalltalk source control is varied. Various projects map image representation of classes onto file based representation in CVS, SVN and so on. Packages in general mean the mapping of a subset of the image onto an external source control construct. I.e. a modularisation of the image that can be shared in a distributed developer environment. Various Smalltalks do this in various ways. The dominant squeak derived system is Monticello. A class category can be mapped onto a Monticello package. Monticello defines a file format which is the physical representation of the package. It provides tools to manage these packages. Part of the complexity currently is that you are not forced to have the system cleanly separated into packages. You can leave bits of the system unpackaged and you currently have to bootstrap (at some point in history) the source management (package) system into an image based on categories. Since there is an overlap of design concerns and implementations it is not obvious what tools or file formats do what. In general in Pharo there is a desire to move towards a more modular system. There is a desire to cleanly bootstrap this system from some kernel specification. Ideally we would then have a namespace implementation that allowed us to isolate and load conflicting code. We also need package dependency management and do on. You will see references to these goals and discussions on all these topics from time to time. Some of these are implemented, some of these are deprecated, and the wish list is long. You wouldn't really start out fresh with the combination of concepts and implementations we currently have in Pharo. Not sure what collections are in this context. Hope that helps Mike On 5 Jan 2012, at 08:37, "Gerry Weaver" <gerryw(a)compvia.com> wrote: > Hi Michael, > > Well... that actually makes good sense (maybe the terminology is my issue). I think I've written C code for so long that I get too bogged down in the details. So, what exactly is a category vs a collection vs a package?. I seems like a category is just a mechanism for organizing code?. I guess a package would be like a Lisp module or C library? What about collections? > > > Thanks for your help. It really did help. > Gerry > > > > -----Original Message----- >> From: "Michael Roberts" <mike(a)mjr104.co.uk> >> To: Pharo-project(a)lists.gforge.inria.fr >> Date: 01/05/12 02:18 >> Subject: Re: [Pharo-project] Pharo by Example >> >> On 5 Jan 2012, at 05:50, "Gerry Weaver" <gerryw(a)compvia.com> wrote: >> >>> Hi, >>> >>> Perhaps I should just take a shot at explaining what I'm having trouble understanding. >>> >>> >>> My current take on the environment is that an image is basically a container that holds everything in the application. >> >> Indeed. >> >>> In development mode it also includes the IDE and tools. >> >> For general Pharo images there is no "mode". They all contain some set of development tools. To remove them you have to go to some effort (stripping) or find a smaller seed image that does not contain them (expert). >> >>> I assume one would typically start by defining a class that was a subclass of some system or package class. >> >> You could start with Object. >> >>> I assume this process would continue until the application logic and data were defined. >> >> Yes >> >>> I also assume that there must be a way to indicate the class that represents the top level or entry point (main) of the application. >> >> Not really. There is no main() as there is in C. There is an entry point for the whole system and this triggers the start of the UI and other services. If you want your application to start on system start you need to register it on the startup list (or whatever the current abstraction is.) >> >> For development you can register the start on a world menu or just use a workspace to evaluate the starting expression. >> >>> That appears to be the init method. Is this anywhere close to being correct? >>> >>> >>> The problem is that I'm not sure how to get started. I have played around with the system browser a bit. I can see that you would create a category and be presented with what looks to be a template for a class. I'm confused about the fact that the "Pharo by Example" has me creating a package when I don't see that in the 1.3 browser. >> >> So for PBE you have to run the exact image the book was targeted for and the examples should work. >> >>> I also don't know how to create additional classes in that category or how to tell the environment which class is my application entry point. I figure maybe the answer to all of this is a little too much for a mailing list question, which is why I didn't start out asking this. Anyway, at least this gives you an idea of where I'm stuck. Maybe my brain just isn't wired to understand something that may be obvious to others. >>> >> >> So for the standard/original system browser I would do the following. In the left most pane you can context click and create a new category 'example'. You get shown a class template in the bottom pane that is an expression to make a class. Type the name of the subclass e.g. ExampleClass into the text where it says NameOfSubclass and context click accept. This makes the new class. On the class side (the button class) define a method go. To do this you need the method template. Normally you get this selecting one of the method protocols. You can replace the method template with something like >> >> go >> FillInTheBlankMorph request: 'hello' >> >> And context click accept. Now open a workspace. Evaluate >> >> ExampleClass go >> >> It should pop up a dialog. That's really it. The "application" runs and then stops. >> >> To make more classes click on the class category again. Type a new class name on and accept it. The new class should appear alongside the other one and you can add methods to it. >> >> Hope that helps. >> Mike >> >> >>> >>> Thanks, >>> Gerry >>> >>> >>> >>> >>> -----Original Message----- >>>> From: "Serge Stinckwich" <serge.stinckwich(a)gmail.com> >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Date: 01/04/12 23:04 >>>> Subject: Re: [Pharo-project] Pharo by Example >>>> >>>> On Thu, Jan 5, 2012 at 11:45 AM, Gerry Weaver <gerryw(a)compvia.com> wrote: >>>>> Hi, >>>>> >>>>> I've been trying various downloads, but I haven't found anything that works. I guess I may be making it harder than it needs to be, but I really have no idea how to proceed. I've been trying to find some doc on basic things like creating a package, class, etc., but I'm not having much luck. I assume the docs will be updated at some point. Would anyone have a feel for when that might be? I'm not in a hurry at all, so I could wait for a couple of more versions. >>>> >>>> Could give us more information about what is not working exactly ? >>>> Did you upload the file here: >>>> https://gforge.inria.fr/frs/download.php/27023/PBE-1.0.zip >>>> and try the exemple in the book ? >>>> >>>> Regards, >>>> -- >>>> Serge Stinckwich >>>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >>>> Matsuno Laboratory, Kyoto University, Japan (until 12/2011) >>>> http://www.mechatronics.me.kyoto-u.ac.jp/ >>>> Every DSL ends up being Smalltalk >>>> http://doesnotunderstand.org/ >>> >>> >>> >>> > > > >

Jan. 7, 2012

Re: [Pharo-project] Cog+linux: external module not found

by Schwab,Wilhelm K

It would also be nice to see (either via syslog()/OutputDebugString()) or (if possible) in the error itself, what library (full path) was being loaded. The output will generally be of interest only when something fails. Similar comments would apply to serial ports that won't open - what did the vm actually try to do when something failed? Most problems that I have had with getting Pharo to open something (library or port) have been relatively obvious to solve as soon as I saw how my intent was translated before it was passed on to the hardware (e.g. /usr/lib//this/that/something.so). Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Mariano Martinez Peck [marianopeck(a)gmail.com] Sent: Saturday, January 07, 2012 5:20 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Cog+linux: external module not found BTW, Eliot, is there a way so that FFI throws something different from "Module not found" when the module is there but not 32 bits? like "Module found but it is not 32 bits" ? cheers On Sat, Jan 7, 2012 at 10:04 AM, Nick Ager <nick.ager(a)gmail.com<mailto:nick.ager@gmail.com>> wrote: Hi Bill, Have you tried strace to determine what library it's failing to load? Nick On 7 January 2012 03:26, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Eliot, There is no /lib32 or /usr/lib32. As a double check, locate lib32 returns nothing. I put the library in /usr/lib, which is what I have done on two other Lucid systems. ldconfig shows it registered there. What's next? Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com>] Sent: Friday, January 06, 2012 7:29 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Cog+linux: external module not found On Fri, Jan 6, 2012 at 4:18 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Paul, The library is 32 bit - I build it from source because it ships with 64 bit binaries. Then try changing your LD_LIBRARY_PATH to /lib32:/usr/lib32:$LD_LIBRARY_PATH and see if that helps (if you have /lib32 & /usr/lib32 that is) Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Paul DeBruicker [pdebruic(a)gmail.com<mailto:pdebruic@gmail.com>] Sent: Friday, January 06, 2012 6:59 PM To: pharo-project(a)lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Cog+linux: external module not found Schwab,Wilhelm K wrote > > Eliot, > > I'm getting the same error with your latest VM. Any ideas? > > Bill > > > When I had trouble with this it was a 64bit vs 32bit library mismatch on a 64bit OS. Is it a 32 bit or 64 bit OS? Is the library you're trying to reach 32bit? 64bit libs won't work with the 32bit CogVM, but are installed by default by the Ubuntu package manager on a 64bit Ubuntu. Ubuntu also moved some mandatory (from Cog's perspectvie) 32 bit libs from their ia32-libs package to the ia32-libs-multiarch recently but I don't know if that change affects Lucid. -- View this message in context: http://forum.world.st/Cog-linux-external-module-not-found-tp4271136p4271354… Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- best, Eliot -- Mariano http://marianopeck.wordpress.com

Jan. 7, 2012

Re: [Pharo-project] Bug in FileSystem

by Nicolas Cellier

2012/1/7 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: > On 07.01.2012 14:05, Henrik Sperre Johansen wrote: >> >> On 07.01.2012 13:20, StÃ©phane Ducasse wrote: >>> >>> sounds like :) >>> >>> Stef >>> >>> On Jan 7, 2012, at 1:10 PM, Mariano Martinez Peck wrote: >>> >>>> FSReadStream>> Â next: count >>>> Â Â | result | >>>> Â Â result := ByteArray new: count. >>>> Â Â handle at: position read: result startingAt: 1 count: count. >>>> Â Â position := position + 1. >>>> Â Â Â ^ result >>>> >>>> >>>> shouldn't be >>>> >>>> FSReadStream>> Â next: count >>>> Â Â | result | >>>> Â Â result := ByteArray new: count. >>>> Â Â handle at: position read: result startingAt: 1 count: count. >>>> Â Â position := position + count. >>>> Â Â Â ^ result >>>> >>>> At least with that (among some extensions) Fuel tests pass with FS :) >>>> >>>> Cheers >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >> Still wrong though, I think... >> It doesn't handle the case where you try to read past end of stream. >> >> next: count >> ^self nextInto: (ByteArray new: count) >> >> would probably be better. >> >> Cheers, >> Henry >> >> > As for the API: > > 1) There's no next: into: (which returns the amount read). It's really the > only way to do buffers without garbage allocations. > 2) FSHandle >>at: offset read: buffer startingAt: start count: count is a > weirdly named selector for what it does imho... > Doesn't #at: offset read: count into: buffer startingAt: start Â make more > sense? > Sure. But without reading source code I also wonder why mixing two operations into a single ? I mean seek() and read() Since the underlying OS handle is most probably a stream, it should preserve its own position. Is it because the handle might be shared and FS thus has to provide some kind of atomic operation ? Nicolas > Cheers, > Henry >

Jan. 7, 2012

Re: [Pharo-project] Cog+linux: external module not found

by Schwab,Wilhelm K

Nick, I didn't know about it, but it looks like a really good thing to try. Thanks! Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Nick Ager [nick.ager(a)gmail.com] Sent: Saturday, January 07, 2012 4:04 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Cog+linux: external module not found Hi Bill, Have you tried strace to determine what library it's failing to load? Nick On 7 January 2012 03:26, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Eliot, There is no /lib32 or /usr/lib32. As a double check, locate lib32 returns nothing. I put the library in /usr/lib, which is what I have done on two other Lucid systems. ldconfig shows it registered there. What's next? Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com>] Sent: Friday, January 06, 2012 7:29 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Cog+linux: external module not found On Fri, Jan 6, 2012 at 4:18 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Paul, The library is 32 bit - I build it from source because it ships with 64 bit binaries. Then try changing your LD_LIBRARY_PATH to /lib32:/usr/lib32:$LD_LIBRARY_PATH and see if that helps (if you have /lib32 & /usr/lib32 that is) Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Paul DeBruicker [pdebruic(a)gmail.com<mailto:pdebruic@gmail.com>] Sent: Friday, January 06, 2012 6:59 PM To: pharo-project(a)lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Cog+linux: external module not found Schwab,Wilhelm K wrote > > Eliot, > > I'm getting the same error with your latest VM. Any ideas? > > Bill > > > When I had trouble with this it was a 64bit vs 32bit library mismatch on a 64bit OS. Is it a 32 bit or 64 bit OS? Is the library you're trying to reach 32bit? 64bit libs won't work with the 32bit CogVM, but are installed by default by the Ubuntu package manager on a 64bit Ubuntu. Ubuntu also moved some mandatory (from Cog's perspectvie) 32 bit libs from their ia32-libs package to the ia32-libs-multiarch recently but I don't know if that change affects Lucid. -- View this message in context: http://forum.world.st/Cog-linux-external-module-not-found-tp4271136p4271354… Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- best, Eliot

Jan. 7, 2012

Re: [Pharo-project] Bug in FileSystem

by Henrik Sperre Johansen

On 07.01.2012 14:05, Henrik Sperre Johansen wrote: > On 07.01.2012 13:20, StÃ©phane Ducasse wrote: >> sounds like :) >> >> Stef >> >> On Jan 7, 2012, at 1:10 PM, Mariano Martinez Peck wrote: >> >>> FSReadStream>> next: count >>> | result | >>> result := ByteArray new: count. >>> handle at: position read: result startingAt: 1 count: count. >>> position := position + 1. >>> ^ result >>> >>> >>> shouldn't be >>> >>> FSReadStream>> next: count >>> | result | >>> result := ByteArray new: count. >>> handle at: position read: result startingAt: 1 count: count. >>> position := position + count. >>> ^ result >>> >>> At least with that (among some extensions) Fuel tests pass with FS :) >>> >>> Cheers >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> > Still wrong though, I think... > It doesn't handle the case where you try to read past end of stream. > > next: count > ^self nextInto: (ByteArray new: count) > > would probably be better. > > Cheers, > Henry > > As for the API: 1) There's no next: into: (which returns the amount read). It's really the only way to do buffers without garbage allocations. 2) FSHandle >>at: offset read: buffer startingAt: start count: count is a weirdly named selector for what it does imho... Doesn't #at: offset read: count into: buffer startingAt: start make more sense? Cheers, Henry

Jan. 7, 2012

Re: [Pharo-project] Bug in FileSystem

by Henrik Sperre Johansen

On 07.01.2012 13:20, StÃ©phane Ducasse wrote: > sounds like :) > > Stef > > On Jan 7, 2012, at 1:10 PM, Mariano Martinez Peck wrote: > >> FSReadStream>> next: count >> | result | >> result := ByteArray new: count. >> handle at: position read: result startingAt: 1 count: count. >> position := position + 1. >> ^ result >> >> >> shouldn't be >> >> FSReadStream>> next: count >> | result | >> result := ByteArray new: count. >> handle at: position read: result startingAt: 1 count: count. >> position := position + count. >> ^ result >> >> At least with that (among some extensions) Fuel tests pass with FS :) >> >> Cheers >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > Still wrong though, I think... It doesn't handle the case where you try to read past end of stream. next: count ^self nextInto: (ByteArray new: count) would probably be better. Cheers, Henry

Jan. 7, 2012

Re: [Pharo-project] Process questions about configurationOfâ¦.

by Ben Coman

StÃ©phane Ducasse wrote: > Hi guys > > What is the process we want? > What I would like is > > MetaRepoForPharo13Inbox were everybody can write > and a jenkins process that loads every published version > and try to load it (after we will run tests and check rules). > depending on the result the configuration is promoted > into > MetaRepoForPharo13 > or > MetaRepoForPharo13Broken > > At the end of the month we will have one engineer working on jenkins and I would like to ask him > to start to put in place this process. > > What do you think? > > Stef > > Some questions out of curiosity since I'm not yet involved in publishing any packages Is there some way to tag for the submitter to be emailed the Jenkins results? Perhaps a method like 'emailJenkinsResultsTo:' inthe configuration or alternatively Jenkins might unzip the mcz to directly search the ".st" files for a specific string. As I understand it, the ConfigurationOfXXX contains information on multiple versions and multiple platforms. Thinking ahead to when there is a MetaRepoForPharo14, are there any concerns keeping two versions of ConfigurationOfXXX in sync between the two repos? For example when an application releases a new version for Pharo13, do you only update the ConfigurationOfXXX in MetaRepoForPharo13? And do you then end up with further forks for ConfigurationOfXXX on other platforms? What about a single repository (if not the existing MetacelloRepository then perhaps MetaRepoCI), which Jenkins processes and then if that single file works for Pharo13 it is copied toMetaRepoForPharo13 and if it works for Pharo14 then it is copied to toMetaRepoForPharo14. Other platforms can do the same. That way the application developer has to manage a single location. cheers, Ben

Jan. 7, 2012

Re: [Pharo-project] Bug in FileSystem

by StÃ©phane Ducasse

sounds like :) Stef On Jan 7, 2012, at 1:10 PM, Mariano Martinez Peck wrote: > FSReadStream >> next: count > | result | > result := ByteArray new: count. > handle at: position read: result startingAt: 1 count: count. > position := position + 1. > ^ result > > > shouldn't be > > FSReadStream >> next: count > | result | > result := ByteArray new: count. > handle at: position read: result startingAt: 1 count: count. > position := position + count. > ^ result > > At least with that (among some extensions) Fuel tests pass with FS :) > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 7, 2012