October 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] flow: a living full-stack #âframework for the web

by Sebastian Sastre

Iâm doing one thing at the time. Iâve started with the read me and requisites and FAQ A tutorial would be great indeed but I think Iâll do a screencast first and pair with people to get strong validation of the most valuable problems people faces first Your feedback would be great On Oct 6, 2014, at 2:36 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Great ! > > Wasn't there a step by step tutorial somewhere ? > > On 05 Oct 2014, at 23:04, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> Hi guys, >> >> Iâm sharing slides of my presentation at CampSmalltalkVI2014 >> http://www.slideshare.net/sebastianconcept/flow-39897704 >> >> >> From flowâs readme at github: >> >> Flow's mission is to provide consultants, startups and software houses with a competitive Smalltalk full-stack framework that allows them to quickly deliver a demo with all the modern html5 features the market expects today (2014). The idea is that they can tactically use this framework to keep momentum up among their prospects and clients and scale things to full successful projects delivered by kickass productive teams or individuals. >> >> sebastian >> >> o/ >> >> blog: http://sebastianconcept.com >> LinkedIn: http://www.linkedin.com/in/sebastiansastre >> github: https://github.com/sebastianconcept >> >> >> >> >> > >

Oct. 7, 2014

Re: [Pharo-dev] [ANN] flow: a living full-stack #âframework for the web

by Sebastian Sastre

great! If it doesnât feel productive is broken and should be fixed so please let me know if you find bumps so I can continue smashing them to ease adoption On Oct 6, 2014, at 2:28 AM, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > > Abs great .. !.. https://github.com/flow-stack/flow have yet to install and check if it has any issues in my system. > > Will check it out, infact have a hackathon to see if this can be tried out on it. > > Nice framework to demo Smalltalk to the crowd in a banking world.. > > > > On Mon, Oct 6, 2014 at 2:34 AM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Hi guys, > > Iâm sharing slides of my presentation at CampSmalltalkVI2014 > http://www.slideshare.net/sebastianconcept/flow-39897704 > > > From flowâs readme at github: > > Flow's mission is to provide consultants, startups and software houses with a competitive Smalltalk full-stack framework that allows them to quickly deliver a demo with all the modern html5 features the market expects today (2014). The idea is that they can tactically use this framework to keep momentum up among their prospects and clients and scale things to full successful projects delivered by kickass productive teams or individuals. > > sebastian > > o/ > > blog: http://sebastianconcept.com > LinkedIn: http://www.linkedin.com/in/sebastiansastre > github: https://github.com/sebastianconcept > > > > > >

Oct. 7, 2014

Re: [Pharo-dev] [ANN] flow: a living full-stack #âframework for the web

by Sebastian Sastre

I donât know, flow is a mission with a curated framework (so itâs mission first) What you can see is flowâs features being done here: https://trello.com/b/NVqhll4I/flow And you are welcome to take a card and push the feature you need running Iâm pushing the ones I need most for the demos Iâm doing for my clients like... now :) Itâs being awesome for corporate innovation indeed A screencast is in my todo list and the petshop sample app is already in the repo (incomplete at this point but has a couple of screens) On Oct 6, 2014, at 1:40 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Sebastian, > > Interesting. Is there a relation between flow and Tide? > > Cheers, > Doru > > > > On Sun, Oct 5, 2014 at 11:04 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Hi guys, > > Iâm sharing slides of my presentation at CampSmalltalkVI2014 > http://www.slideshare.net/sebastianconcept/flow-39897704 > > > From flowâs readme at github: > > Flow's mission is to provide consultants, startups and software houses with a competitive Smalltalk full-stack framework that allows them to quickly deliver a demo with all the modern html5 features the market expects today (2014). The idea is that they can tactically use this framework to keep momentum up among their prospects and clients and scale things to full successful projects delivered by kickass productive teams or individuals. > > sebastian > > o/ > > blog: http://sebastianconcept.com > LinkedIn: http://www.linkedin.com/in/sebastiansastre > github: https://github.com/sebastianconcept > > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 7, 2014

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

by Esteban A. Maringolo

2014-10-06 22:26 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > Dialect>>someWorkingMethod > Transcript show: Dialect myWhoAmI. > What is not to like? :) > Could I reopen that ticket(renamed "Introduce dialect testing classes")? I prefer feature detection, but if you go through this Dialect thing please use something else as the name of the root class instead of plain "Dialect". E.g. SmalltalkDialect. :) Regards!

Oct. 7, 2014

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

by Ben Coman

Jan Vrany wrote: > OK. > > I think enough has been said. No need to waste more time on it. > I closed the issue. > Thanks Nicolai for making the slice for me! > > Best, Jan Thanks for the attempt. Even though I didn't like the isAxxx pattern, and feature testing is better, you have me thinking that a common paradigm for dialect testing in a more OO fashion could be useful. There was no feedback on my earlier proposal. I've refactored it slightly. I see the following advantages: * Promotes an OO pattern * Low overhead is USER code for a "small" number of methods * When you grow beyond a "small" number of such methods, its easier to refactor them out to your own dialect specific classes. ====WITH THE FOLLOWING IN ALL SMALLTALK DIALECT RELEASES==== Object subclass: Dialect classVariable: 'CurrenDialect'. ---- Dialect subclass: DialectPharo. ---- Dialect subclass: DialectVAST. ---- Dialect>>dialect " ^ DialectPharo " "In Pharo" " ^ DialectVAST " "In VAST" ====USERS COULD HAVE THE FOLLOWING AS EXTENSIONS==== Dialect>>myWhoAmI self dialect myMethod: aString" ---- DialectPharo>>myWhoAmI ^ 'I am Pharo' ---- DialectVAST>>myWhoAmI ^ 'I am VAST' ---- ====USED LIKE THIS==== Dialect>>someWorkingMethod Transcript show: Dialect myWhoAmI. What is not to like? :) Could I reopen that ticket(renamed "Introduce dialect testing classes")? cheers -ben > > > On Sat, 2014-10-04 at 21:14 +0100, Jan Vrany wrote: >> Hi guys, >> >> I've just opened: >> >> https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-met… >> >> Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to >> SmalltalkImage to ease multi-dialect development. >> >> RATIONALE: >> >> Commonly used approach to solve differences among dialect is to use a >> sort of platform object and dispatch there for troublesome operations >> that has to be specialized. This platform object is usually in platform >> specific package. >> Other option is to load some library like Grease or Sport. >> >> The problem of the first approach is that brings to much (unnecessary) >> burden when used for two, three things. The amount of of the code and >> management is way to bigger then the amount of the code that has to be >> specialized. Loading Grease/Sport on the other hand introduces a >> dependency on an external package - not worth of for two or three >> things. >> >> The proposed dialect testing messages would allow for simple, >> #ifdef-like idiom like: >> >> | stream | >> ... >> ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk >> isSomeCoolDialect]) ifTrue:[ >> stream := CharacterWriteStream on: (String new: 10) >> ] ifFalse:[ >> stream := WriteStream on: (String new: 10) >> ] >> >> The #respondsTo: check, while not nice, is required as at the moment not >> all dialects could be trusted to have these testing messages. >> >> Putting these methods may not stick with Pharo standard (whatever it >> is), but Smalltalk global is probably one of the >> very few that are present in pretty much every Smalltalk implementation. >> Other option would be to place them to the class side of an Object >> (which is amost certainly present everywhere), however >> >> Smalltalk isPharo >> >> reads better than >> >> Object isPharo. >> >> Best, Jan >> >> > > > >

Oct. 7, 2014

Re: [Pharo-dev] ANNC: QR Code (v.2)

by Pablo R. Digonzelli

excellent! thanks Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 ----- Mensaje original ----- De: "Esteban A. Maringolo" <emaringolo(a)gmail.com> Para: "Pharo Development List" <pharo-dev(a)lists.pharo.org> Enviados: Lunes, 6 de Octubre 2014 14:21:58 Asunto: Re: [Pharo-dev] ANNC: QR Code (v.2) Cool! Thank you Jeff. Esteban A. Maringolo 2014-10-06 12:49 GMT-03:00 J.F. Rick <self(a)je77.com>: > I've got a new version of the QR Code generator: > http://smalltalkhub.com/#!/~JochenRick/QRCode > > This one includes support for MicroQR, for UTF-8 encoding and other aspects > of the latest QR standard (e.g., mirroring). I've also written a small Zinc > web app which makes it easy to try out. > > Enjoy! > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick

Oct. 6, 2014

Re: [Pharo-dev] GT-Inspectors need live updating

by Tudor Girba

Hi, On Mon, Oct 6, 2014 at 11:35 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I understand, but even with those impressive graphical views, it would be > really cool if updates happened automagically, right ? Add something to a > collection, graphs updated.... > That is absolutely so. > Would it not be an idea that presentations can 'opt out' of updating, > because they know things take too much time, while other, simpler ones can > 'opt in'. Or maybe choose a slower updating cycle, skipping intermediate > steps - just thinking out loud. > Something in this direction. > Working with the GT presentations, I sense that some performance issue > will come up, I just decided to ignore them for now. We should prototype a bit :) Cheers, Doru > On 06 Oct 2014, at 23:29, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > > I want that, too. But, the problem is that having it generically for any > presentation is not working safely. Some presentations can be heavy on > computations, and having them refresh on the #step can be way too heavy. > > > > One solution would be to refresh presentations selectively, but that is > not so nice. Or we have to find a smarter way. > > > > Doru > > > > On Mon, Oct 6, 2014 at 11:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > I meant *without* an extra process, of course. > > > > It seems to be in EyeInspector>>#step -> EyeInspector>>#refresh. > > > > BTW, it ***really, really*** is needed for live object demos, no way > around it. > > > > On 06 Oct 2014, at 23:18, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > > Hi, > > > > > > Indeed. Not having live update by default was a conscious decision > because we did not find a solution that scales properly both for several > inspectors and for heavy computations of presentations. It would be great > if someone could propose a way to go. > > > > > > Cheers, > > > Doru > > > > > > > > > > > > On Mon, Oct 6, 2014 at 11:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > It seems that currently there is no automatic live updating for > GT-Inspectors. > > > > > > That has to be fixed since we had that in both the old and in the eye > inspectors. > > > > > > I remember Stef did something to do this with an extra process. > > > > > > Sven > > > > > > > > > > > > -- > > > www.tudorgirba.com > > > > > > "Every thing has its own flow" > > > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 6, 2014

Re: [Pharo-dev] gt issues

by Sven Van Caekenberghe

On 06 Oct 2014, at 23:33, Tudor Girba <tudor(a)tudorgirba.com> wrote: > For preserving inspectors on independent objects, we need another solution. I believe for this case, we could simply use a kind of a clipboard for objects that can be inspected at a later time. Yes, I often use an ObjectClipboard global variable to do that manually...

Oct. 6, 2014

Re: [Pharo-dev] GT-Inspectors need live updating

by Sven Van Caekenberghe

I understand, but even with those impressive graphical views, it would be really cool if updates happened automagically, right ? Add something to a collection, graphs updated.... Would it not be an idea that presentations can 'opt out' of updating, because they know things take too much time, while other, simpler ones can 'opt in'. Or maybe choose a slower updating cycle, skipping intermediate steps - just thinking out loud. Working with the GT presentations, I sense that some performance issue will come up, I just decided to ignore them for now. On 06 Oct 2014, at 23:29, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I want that, too. But, the problem is that having it generically for any presentation is not working safely. Some presentations can be heavy on computations, and having them refresh on the #step can be way too heavy. > > One solution would be to refresh presentations selectively, but that is not so nice. Or we have to find a smarter way. > > Doru > > On Mon, Oct 6, 2014 at 11:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I meant *without* an extra process, of course. > > It seems to be in EyeInspector>>#step -> EyeInspector>>#refresh. > > BTW, it ***really, really*** is needed for live object demos, no way around it. > > On 06 Oct 2014, at 23:18, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > > Indeed. Not having live update by default was a conscious decision because we did not find a solution that scales properly both for several inspectors and for heavy computations of presentations. It would be great if someone could propose a way to go. > > > > Cheers, > > Doru > > > > > > > > On Mon, Oct 6, 2014 at 11:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > It seems that currently there is no automatic live updating for GT-Inspectors. > > > > That has to be fixed since we had that in both the old and in the eye inspectors. > > > > I remember Stef did something to do this with an extra process. > > > > Sven > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 6, 2014

Re: [Pharo-dev] gt issues

by Tudor Girba

Hi Christophe, We will start with adding the possibility of closing the last pane. It is unlikely that we will add closing of random panes in the inspector because the main purpose of those panes is to preserve the navigation path. For preserving inspectors on independent objects, we need another solution. I believe for this case, we could simply use a kind of a clipboard for objects that can be inspected at a later time. Cheers, Doru On Mon, Oct 6, 2014 at 2:42 PM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > Hello, > > Le 4 oct. 2014 Ã 11:51, Tudor Girba a Ã©crit : > > Pharo needs a centralised way to manage tabs and windows, its a system >> heavily .... wait that is wrong.... solely based on GUIs. So this is not a >> GT issue, its more a Pharo issue. >> > The problem with GT because is such a detailed tool it exposes this Pharo >> weakness a lot more than other tools. >> > > The GTInspector problem will be solved by adding the possibility for each > last tab to close. > > > Please, add these feature for all tabs (maybe not for the first one but it > does not matter). > I often need to hide/close intermediates tabs that are just there because > they were needed for the navigation. At the end, I just want to keep > inspectors on objects I want to look at. > > Regards, > Christophe. > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 6, 2014