January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Smalltalk for small projects only?

by Janko MivÅ¡ek

Wow guys, it is nice for me to see that this thread raised some fruits already and it seems it will even more in the future :) Best regards Janko S, Dale Henrichs piÅ¡e: > Otto, > > This looks very interesting! Since you are still using Monticello, I think it should be very straightforward to add the file tree repository type to Metacello as a starting point, although I'm sure that more support is needed than just that.. > > I am in the middle of working on the next release for Metacello, so now is a good time to integrate smallsource support into Metacello, please drop me a line and give me your thoughts on the direction you think things need to go... > > Dale > > ----- Original Message ----- > | From: "Otto Behrens" <otto(a)finworks.biz> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Sunday, January 29, 2012 2:03:42 PM > | Subject: Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only? > | > | Hi, > | > | We've built a little package that allows us to save all our source in > | git. We've been developing with this for 3 months now, and it's > | pretty > | stable. I put a project on github, > | https://github.com/finworks/smallsource that contains some more info > | on it. Yes, there's more work to do, but there's hope. The repo > | contains some examples that I just saved from the image. > | > | In short, we save and load all the monticello packages on our project > | as smalltalk source files. We use git to merge and not monticello. We > | use metacello, but watered down to essentially just dependencies. > | > | I just want to say thanks to all you people who put in such great > | effort into Smalltalk. We are using Smalltalk to create a business > | and > | are slowly getting somewhere. > | > | We've been using git for about 3 years now. This came from a need to > | manage files, such as scripts, resources (images and stuff), > | documents > | and recorded selenium (ide) tests with smalltalk code. So, we just > | whacked all of this, including our monticello packages into the git > | repo. > | > | As you can imagine, storing binary files in a git repo, especially > | fairly large packages and lots of integrations / merges / versions, > | grew the git repo quite a bit. We also needed to clone the git repo > | all over. So we decided to give it a shot and write to files. > | > | It took about 2 weeks to get going and another to sort out some pain, > | but the package in the smallsource repo have not changed for 3 > | months. > | > | We are 5-6 developers on the project, committing numerous times a > | day. > | We currently have about 1100 classes (find repo -type d | wc -l > | gives > | us 2200) and 23500 methods (find . -type f | grep -v "mcz$" | wc -l > | gives us 23545) managed in this way. > | > | I'm keen to talk about how we can really "do the right thing" and > | solve this source code management monster. I know this approach needs > | work (I'll list some issues on the project, that I think needs > | attention) and I also realise that there could be better approaches. > | > | Here's another idea: we can map class definitions and method > | definitions directly to git objects. Git has a great object model > | which will allow us to directly track the complete history of a > | method > | or class definition, with commit details and what not. In a sense, I > | feel that a tight integration between a smalltalk environment and git > | will be a fantastic solution - something like envy, but on git, with > | all the fanciness that comes with git! > | > | The only problem with this is a very tight coupling with git. Do we > | want that? > | > | Thanks again > | Otto > | > | > > -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Jan. 30, 2012

Re: [Pharo-project] PseudoContext?

by Eliot Miranda

On Mon, Jan 30, 2012 at 2:39 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > I will with pleasureâ¦. > Also think of getting rid of TranslatedMethod and BlockContext if you haven't already. Also, collapsing ContextPart and MethodContext onto just Context (or ActivationContext (?)) would be nice. > Stef > > On Jan 30, 2012, at 9:50 AM, Mariano Martinez Peck wrote: > > > > > > > On Sun, Jan 29, 2012 at 10:53 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > I don't see any PseudoContext in squeak trunk, you can reasonably not > > afford to be dirtier ;) > > > > > > YES!! And this class got me crazy once because it subclass from nil !! > > BTW, we should also fix the senders of #isPseudoContext if we remoev the > class. > > > > > > 2012/1/29 Marcus Denker <marcus.denker(a)inria.fr>: > > > > > > On Jan 29, 2012, at 6:02 PM, StÃ©phane Ducasse wrote: > > > > > >> Hi > > >> > > >> I have the impression that PseudoContext is not used anymore. At > least compact class array and special object array > > >> do not use it anymore. So what is the use for this class? > > >> > > > I think it was only used by Ian's original Jitter... which means 10 > years unused. > > > We should remove it. > > > > > > Marcus > > > > > > > > > -- > > > Marcus Denker -- http://marcusdenker.de > > > > > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- best, Eliot

Jan. 30, 2012

Re: [Pharo-project] NonInteractiveUIManager

by Sven Van Caekenberghe

On 30 Jan 2012, at 17:20, StÃ©phane Ducasse wrote: > Seems so because I do not understand anything. > > Stef > > On Jan 30, 2012, at 12:23 PM, Sven Van Caekenberghe wrote: > >> When making syntax errors in a startup script you get >> >> SubclassResponsibility: a NonInteractiveUIManager had the subclass responsibility to implement #syntaxErrorNotificationDefaultAction: >> >> Would it not be a better idea to just handle and print the syntax error ? >> >> Sven I am not that sure what to do exactly either, I turned this into an issue: http://code.google.com/p/pharo/issues/detail?id=5227 Igor ? Sven

Jan. 30, 2012

Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

by Dale Henrichs

Otto, This looks very interesting! Since you are still using Monticello, I think it should be very straightforward to add the file tree repository type to Metacello as a starting point, although I'm sure that more support is needed than just that.. I am in the middle of working on the next release for Metacello, so now is a good time to integrate smallsource support into Metacello, please drop me a line and give me your thoughts on the direction you think things need to go... Dale ----- Original Message ----- | From: "Otto Behrens" <otto(a)finworks.biz> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Sunday, January 29, 2012 2:03:42 PM | Subject: Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only? | | Hi, | | We've built a little package that allows us to save all our source in | git. We've been developing with this for 3 months now, and it's | pretty | stable. I put a project on github, | https://github.com/finworks/smallsource that contains some more info | on it. Yes, there's more work to do, but there's hope. The repo | contains some examples that I just saved from the image. | | In short, we save and load all the monticello packages on our project | as smalltalk source files. We use git to merge and not monticello. We | use metacello, but watered down to essentially just dependencies. | | I just want to say thanks to all you people who put in such great | effort into Smalltalk. We are using Smalltalk to create a business | and | are slowly getting somewhere. | | We've been using git for about 3 years now. This came from a need to | manage files, such as scripts, resources (images and stuff), | documents | and recorded selenium (ide) tests with smalltalk code. So, we just | whacked all of this, including our monticello packages into the git | repo. | | As you can imagine, storing binary files in a git repo, especially | fairly large packages and lots of integrations / merges / versions, | grew the git repo quite a bit. We also needed to clone the git repo | all over. So we decided to give it a shot and write to files. | | It took about 2 weeks to get going and another to sort out some pain, | but the package in the smallsource repo have not changed for 3 | months. | | We are 5-6 developers on the project, committing numerous times a | day. | We currently have about 1100 classes (find repo -type d | wc -l | gives | us 2200) and 23500 methods (find . -type f | grep -v "mcz$" | wc -l | gives us 23545) managed in this way. | | I'm keen to talk about how we can really "do the right thing" and | solve this source code management monster. I know this approach needs | work (I'll list some issues on the project, that I think needs | attention) and I also realise that there could be better approaches. | | Here's another idea: we can map class definitions and method | definitions directly to git objects. Git has a great object model | which will allow us to directly track the complete history of a | method | or class definition, with commit details and what not. In a sense, I | feel that a tight integration between a smalltalk environment and git | will be a fantastic solution - something like envy, but on git, with | all the fanciness that comes with git! | | The only problem with this is a very tight coupling with git. Do we | want that? | | Thanks again | Otto | |

Jan. 30, 2012

Re: [Pharo-project] OneClick on website's first page?

by Janko MivÅ¡ek

S, Norbert Hartl piÅ¡e: >> My intention was dragged into downloads of Shortcuts section and I'm >> also blind to "marketing" images outside the central area, this is >> probably a reason :) But it is only me? > > yes! Are you sure? :) Janko

Jan. 30, 2012

Re: [Pharo-project] Morpheas , bringing Morphic to Opengl (3d GUIs)

by Igor Stasenko

On 30 January 2012 17:42, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > No No No .... I am not asking you to code a line for me or anyone else in > here. I am not fishing for coders Â , or want people to code for my "super > cool" project . At least not until I can provide substantial code to back up > my claims. > I am not proposing to help with coding your actual project, i just providing a support for NativeBoost and NBOpenGL, in case if you choose them to use. > "Too ambitious" is a very polite way to put it, "pure insanity" is more like > it : D > It is not insanity. My first small project when i joined squeak community were GLCanvas, so i am also kind of infected with weird ideas of implementing a novel UIs using opengl and smalltalk. But road is long, and needs to be walked.. and waking with party is much easier and fun. > I am a 32 years old coder, I have been coding for fun for 23 years now and I > dont consider myself a very good coder. So I have a very good idea what I am > getting myself into and I dont want to drag anyone with me. But I was > dreaming for this all my life so one day I woke up and said "what the heck" > even if I can make 1% of this reality I will be very happy. And if I dont, > then I will certainly have alot of fun in the process. > > So exactly what you do now, is exactly what I need. Documentation, > Documentation and you guessed it more Documentation. Â So I fire up the very > first question . > > Where I can find documentation for nativeboost and NBOpenGL ? I am also > interested in the new FFI. > right now, most of it on http://code.google.com/p/nativeboost/w/list we're also writing a book chapter about it, https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Ali… which is work in progress. it is more introductory-style guide. also i started writing more like 'reference' style help, which will be available right in the image using help system > By the way Igor thank you for your amazing work so far with anything you > have done. I only hope my project be able to give you back something as good > u one of the things you have given us. > thanks for valuing my effort :) but frankly my opinion about my work is not that high -- Best regards, Igor Stasenko.

Jan. 30, 2012

Re: [Pharo-project] pharo vision

by dimitris chloupis

Thanks stef for this . The document informed me Â of things I was not aware of and now after reading it I like Pharo even more .Â ________________________________ From: Henrik Johansen <henrik.s.johansen(a)veloxit.no> To: Pharo-project(a)lists.gforge.inria.fr Sent: Monday, 30 January 2012, 18:10 Subject: Re: [Pharo-project] pharo vision On Jan 30, 2012, at 9:24 14AM, StÃ©phane Ducasse wrote: <main.pdf>Nice! Some comments on the parts I'm most familiar with: 3.2 I agree, the nice parts in FS to me is the path manipulation API. Going back to pure ANSI-streams as provided by FSFileStream is not really an option. Since it's a clean break from FileDirectory & friends though, it might be the perfect time to introduce XTreams; -or it might be too much hassle to have to change both parts in existing code at once. A good compromise would be to make it pluggable, using the existing Standard/MultiByteFileStreams by default, but making XStreams pluggable (on a use--by-use basis, so you can write new code with XStreams while maintaining old code where you have only had time to rewrite the path handling) 3.3 "Using ephemerons we can then simplify the Announcement and make sure that clients do not have to worry about weak or not registration." You still have to worry about whether you want weak or strong registration. "Do I have strict requirements for when the announcement should stop being delivered in relation to subscriber lifespan?" is still a valid question. What you don't have to worry about, is what _type_ of subscription (action blocks or message sends), you are allowed to use when registering weakly. Ends with "In addition, " then nothing :) Cheers, Henry

Jan. 30, 2012

Re: [Pharo-project] Morpheas , bringing Morphic to Opengl (3d GUIs)

by dimitris chloupis

No No No .... I am not asking you to code a line for me or anyone else in here. I am not fishing for coders Â , or want people to code for my "super cool" project . At least not until I can provide substantial code to back up my claims.Â "Too ambitious" is a very polite way to put it, "pure insanity" is more like it : DÂ I am a 32 years old coder, I have been coding for fun for 23 years now and I dont consider myself a very good coder. So I have a very good idea what I am getting myself into and I dont want to drag anyone with me. But I was dreaming for this all my life so one day I woke up and said "what the heck" even if I can make 1% of this reality I will be very happy. And if I dont, then I will certainly have alot of fun in the process.Â So exactly what you do now, is exactly what I need. Documentation, Documentation and you guessed it more Documentation. Â So I fire up the very first question .Â Where I can find documentation for nativeboost and NBOpenGL ? I am also interested in the new FFI. By the way Igor thank you for your amazing work so far with anything you have done. I only hope my project be able to give you back something as good u one of the things you have given us.Â ________________________________ From: Igor Stasenko <siguctua(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> Cc: Janko MivÅ¡ek <janko.mivsek(a)eranova.si> Sent: Monday, 30 January 2012, 17:29 Subject: Re: [Pharo-project] Morpheas , bringing Morphic to Opengl (3d GUIs) Too ambitious. I am too old for this ( being there, ate that ), but you can try :) And you have my full support. I am currently writing documentation to cover different aspects of NativeBoost. And of course, i continue my work on Athens, Cairo and NBOpenGL.. someone please lend me the day-stretcher , to have 48 hours/day :) On 30 January 2012 15:55, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > There are no screenshots per se , the project is in "reading documentation > and planning stage", but I have commited a small OpenGL morph that I have > grabed from the croquet repo. Me and some other people at #squeak have been > sucessful at embeding OpengGL context on screen or inside a morph widget. > > you can take a look at my friends Nehe tutorials in Squeak here > > http://www.youtube.com/watch?v=g_YOqIWCcLQ&feature=results_main&playnext=1&… > > I posted here to coordinate effort with all parties and make sure I make my > project 100% compatible with existing Pharo and any future Pharo. > > Each concept is based on an Age that works like a cascade. The one depends > on the other. > > So Proteas will need a stable, reliable and at least basic Morpheas. Proteus > will be a visual programming environment taken to the next level. As you > know already Pharo and smalltalk perform very well for visual programming. > My idea is to take this abit further. > > An idea/theory I want to implement is my "LOD theory" . According to this > idea, not only you can represnt code visualy but you can represent in a > context that moves in Leves Of Detail. This way the user will be able to see > a "bird's eye" vew of the code, visual, meaning graphical blocks / elements > representing section of code which many contain several classes/ objects. > The user will control the level of detail which you will able to see more > and more deeply the structure of you code. Obviously code does not change, > the way you view it changes and help you understand the connection even in > nightmare scenarios like spaggeti code. That means that will implement > several navigational tools for exploring these visualisation and all of them > will depend on the 3d nature of Morpheas. > > Beside code visualisation I would like to take this theory in the actual > inteface as well. For example LOD will appear to all tool like the debugger > , system browser , TDD etc The user will be able to operate those tool in > begineer / advanced and expert modes. > > Code will also be contstucted in a visual ways, obviously something similar > to scratch or build your own blocks, however full acess to the language will > be allowed. Have several ideas there how that is possible. > > Another important theory I want to test is my "real time context sensitive > documentation". In a sense the screen will dedicate one 1/3 or 1/4 of its > estate to a documentation column that will be there all the time unless the > user decides to close it. The documentation will change according to what > the user selects and types making external documentation redundant. This > documentation will of course leverage class documentation strings but it > migh extend the whole facility as well. > > Finally Proteas will operate through a 3d world powered by Morpheas Graphic > Engine, in a style of an RPG game, making sure users around the world can > interact , share code and even collab real time. The RPG game will offer > challanges and tutorials to users and its an oportunity for me to practice > my 3d skills. Obviously I will be borrowing alot of code from Open Cobalt > since this part overlaps in that area. > > Orpheas will be completely made via Proteas and of course Morpheas as a > proof of concept. It will be a DAW GUI for Supercollider. > > A DAW is a Digital Audio Workstaion , its a professional Music software > which has tracks, mixers , eq, audio effects and anything a musician needs > to create polished music tracks. I will use Supercollider as the main engine > here , supercollider is an extremely power audio server that can perform > complicate and sophisticate functions on audio and music by receiving OSC > messages. So you can say that audio wise Opheas will do nothing more than > calling Supercollider functions. > > You can find Supercollider here > > http://supercollider.sourceforge.net/ > > Orpheas will follow Ableton Live as a design model > > http://www.ableton.com/ > > My plan is 2 year for Morpheas then another 2 years for Proteas and then > another 2 years for Orpheas. But its not a strict plan as I said I am still > in planning phase and anything can happen. Hopefull I can get other people > to work on it too, but for the time being I will be alone making sure there > is some gravity on my claims. > > My goal obviously because the project is too ambitious and its pure insanity > to implement all those features by myself is to borrow as much as I can > existing code and reuse it. Â I have many ideas, but I am aware that putting > ideas to practice is "abit" harder than one thinks. Will see how it goes for > the time being my only concetration is Morpheas and how well opengl can work > inside Pharo. > > So anyone who can help me with an advice or a couple of links will provide > me with some very valuable help. > > > ________________________________ > From: Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis > <thekilon(a)yahoo.co.uk> > Sent: Monday, 30 January 2012, 15:58 > Subject: Re: [Pharo-project] Morpheas , bringing Morphic to Opengl (3d GUIs) > > Hi Dimitris, > > Your Ephestos sounds promising, can you post some screenshot as well or > is too early? Also, can you explain us Proteas and Orpheas ... > > Best regards > Janko > > S, dimitris chloupis piÅ¡e: >> I have started my first project with Pharo (and hopefully Squeak too) >> called "Ephestos" . >> >> http://www.squeaksource.com/ephestos.html >> >> Ephestos is divided into 3 areas/ elements / concepts : a) Morpheas b) >> Proteas c) Orpheas >> >> Morpheas is an effort to bring Morphic to OpenGL and to implement 3d >> guis , that can be designed in blender ( probably will implement a addon >> exporter too from blender to Pharo) and deployed in Pharo , minimising >> coding and maximising ease of use, since a 3d gui can be fairly complex >> to program. >> >> The reason why I am posting here is for your help. I am very new to >> Pharo and smalltalk and Ephestos is an extremely ambitious project which >> I hope to be commited for at least the next 5-6 years which I plan to >> release version 1. >> >> My first rule is of course , because the project is already very >> ambitious, "code reuse". I want to be informed what efforts there have >> been towards that direction . >> >> Mr Stef published recently a great PDF documentÂ titled "Pharo's Vision >> : Goals , Processes and Development effort" in it there is the following >> quote about Morphic >> >> "What have been done so far. Igor Stasenko did the following: >> â¢ Designed and implemented a new canvas API and all the necessary >> abstractions >> to generate adequate code for different backends. >> â¢ Deep integration to be able to inject frames into existing VMstructure >> (Igor >> can you confirmthis?) >> â¢ Designed and implemented a new textMorph, paragraph and other classes. >> â¢ Defined a default back-end. >> â¢ Defined a Cairo back-end. >> â¢ Defined an openGL back-end (using an OpenGL calling framework). " >> >> So I guess my question should be directed towards Igor, but maybe >> someone else also works in this. I am interested in any information >> about Morphic and OpenGL . I am also interested even on partial support >> of graphics engine like Irrlicht , Ogre and Open Cobalt. >> >> My main focuse is Nativeboost cause it appear to have a new enhance FFI, >> and of course the possibility of inline Assembly code. >> >> Has anyone , advice , suggestions , ideas and hopefully some >> documentation I can useÂ ? >> >> I am already studying both OpenGL and Nativeboost / NBOpenGL . > > -- > Janko MivÅ¡ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel:Â 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > > -- Best regards, Igor Stasenko.

Jan. 30, 2012

Re: [Pharo-project] pharo vision

by StÃ©phane Ducasse

On Jan 30, 2012, at 4:17 PM, Sean P. DeNigris wrote: > Thanks Steph! This is much-needed to focus our community and avoid > unnecessary confusion and chatter. You got my message :) Thanks for the copy edit. Stef > > A few minor edits to Ch. 1: > pg. 1 > "curved in stone" should be carved > pg. 4 > * "based on an integreation server" should be integration > * "test them and notify its results" should be "tests them and notifies its > results" > * "We will also put in place another level of checks based on integration > servers as well." -> To me this sentence adds nothing. Either explain more > or remove it. > * "We will not do that for the sake of changing." I think you mean "We will > not change for the sake of change." > * "expressing in a more com- pact form all kind of information" would be > more clear as "expressing all kinds of information in a more compact form" > * "optimization at compiler level" -> "optimization at the compiler level" > * "Not only we want that people build" -> "Not only do we want people > build" > pg. 5 > * "We want that both users and the system general quality, benefit from the > best libraries." -> "We want both users and the general quality of the > system to benefit from the best libraries." > * "we want to have validated packages running check rules and automated > tests automatically validated." is unclear, but I don't understand it well > enough to change it > * "*a* good interaction with the rest of the world" should be "good > interaction with the rest of the world" > * "The list *if* not exhaustive but should allow *one* to structure the > development effort." -> "The list is not exhaustive but should allow us to > structure the development effort." > * "New IDES" -> "New IDEs" > * "but also new *way* of handling" -> "but also new ways of handling" > * "of new *kind* of IDEs, desktop metaphor and" -> "of new kinds of IDEs, > desktop metaphor and:" (added colon at end, subsequent bullets are children) > pg. 6 > * "proved that it was worth." Sentence fragment, I'm not clear enough to > fix it > * "and complex *applications*" -> "and complex application" > * "Obviously everybody prefer to use a fast library than a slow one. We > should develop rule checking that include speed regression testing." -> > "Obviously everybody prefers using a fast library over a slow one. We should > develop rule checking that includes speed regression testing." > * "64 bits. For managing large amount of data" -> "64 bits. For managing a > large amount of data" > * "Even if theoretically with a 32 bits VM we should be able to run images > of at least 2 GBs, this is not the case of current available VMs. For > example, the Windows VM does not support images bigger than 512 MB." -> > "Although a 32 bit VM can theoretically run images of up to 2 GB, the > currently available VMs are more limited. For example, the Windows VM does > not support images bigger than 512 MB." > pg. 7 > * "Large applications" section is repeated > * "OpenSophie proved that Smalltalk and Squeak in particular, the ancestor > of Pharo, are good platforms for building advanced multimedia applications. > We believe that Pharo can be used in such situation." -> "OpenSophie proved > that Smalltalk, and Squeak (Pharo's ancestor) in particular, are good > platforms for building advanced multimedia applications. We believe that > Pharo is well-suited for this." > > Sean > > -- > View this message in context: http://forum.world.st/pharo-vision-tp4340345p4341249.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 30, 2012

Re: [Pharo-project] pharo vision

by StÃ©phane Ducasse

Apparently the mail was not for the mailing-list. My fingers wrote it but it was not ready yet. So now you know what I'm working on. Stef On Jan 30, 2012, at 9:24 AM, StÃ©phane Ducasse wrote: > <main.pdf>

Jan. 30, 2012