- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Downloading 1.4

by Johannes Rasche

Hi all, does that mean, that somebody is going to finalize Sean's Quicktime harvesting ? If not, I'm offering to do that job. A few remarks, what has to be done from my point of view (must not be a player like that in Squeak): start pause, stop (removes the morph - BTW, remove via halo leaves a transformation morph) slider volume and mute reposition and resize (not via halo) ExternalDrophandler other than .mov video formats to be checked (what QT player is accepting) - an issue for the plugin (to be done by somebody experienced with plugins and details of video formats) Anyway I'm preparing a concept for that and like to have it reviewed, if you want me to do that job. In this context I also like to mention mp3 harvested kindly from Sophie by Sean as well it didn't work for me, as I tried it yesterday - mp3 format issue - I assume it's due to less maintenance of the mpeg3 plugin ( it seems from old Squeak days and was never touched later ) - did experience that with Squeak as well 2 years or more before Would like to handle this as well, but requires contribution of someone with plugin and mp3 experience I guess Cheers Johannes Am 29.07.2011 um 10:00 schrieb laurent laffont: > > On Fri, Jul 29, 2011 at 1:10 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 28 July 2011 23:36, laurent laffont <laurent.laffont(a)gmail.com> wrote: > > Sean, > > I've tried with a PharoCasts video and it works (OSX Lion, Pharo 1.3, > > Eliot's Cog VM), that's wonderful !!! > > Does it work on Linux / Windows ? I'm thinking about distributing a > > one-click image with PharoCasts videos > > Laurent. > > > > Laurent , feel free to leave a note on cog issue tracker, so sooner or > later we could make it working :) > > > It's here: http://code.google.com/p/cog/issues/detail?id=58 > > I've also added a link to the Cog issue tracker in http://www.pharo-project.org/community/issue-tracking > > Laurent. > > > > > > On Thu, Jul 28, 2011 at 8:46 PM, Sean P. DeNigris <sean(a)clipperadams.com> > > wrote: > >> > >> The code, brief instructions, and a screencast of the result are at > >> http://seandenigris.com/blog/?p=723 > >> > >> Here is the relevant bit to get it working: > >> > >> Gofer new > >> squeaksource: 'MetacelloRepository'; > >> package: 'ConfigurationOfFFI'; > >> load. > >> > >> ((Smalltalk at: #ConfigurationOfFFI) project latestVersion) load. > >> > >> Gofer new > >> squeaksource: 'SophieGoldDig'; > >> package: 'SpdQT'; > >> load. > >> > >> aURI := URI fromString: 'file:///path/to/video.ext'. > >> movie := QuickTimeMovie openMovieFromURI: aURI. > >> m := SqueakMovieMorph openOn: movie. > >> > >> -- > >> View this message in context: > >> http://forum.world.st/Downloading-1-4-tp3696454p3702140.html > >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >> > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Aug. 10, 2011

Re: [Pharo-project] News about NativeBoost

by Igor Stasenko

@Windows users: Since Windows VMs currently not available on Jenkins server, i uploaded a prebuilt VM to NativeBoost project hosting: http://code.google.com/p/nativeboost/downloads/detail?name=nb-cog-win32.zip… I tested if new code works on windows. And after fixing couple of glitches, it working well. I even been able to run true-type font rendering demo, which i made year ago (NBOpenGL project) without changing a bit of code there. -- Best regards, Igor Stasenko AKA sig.

Aug. 10, 2011

Re: [Pharo-project] About configurationOfPharoRB

by StÃ©phane Ducasse

Aug. 9, 2011

Re: [Pharo-project] What are the useful operations of implementors/senders that you use

by StÃ©phane Ducasse

I will wait a bit more and collect a list of essential action to the bug entry I created. Stef On Aug 9, 2011, at 7:28 PM, Nicolas Cellier wrote: > 2011/8/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> On Aug 9, 2011, at 6:29 PM, Nicolas Cellier wrote: >> >>> 2011/8/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> Hi >>>> >>>> I would like that we do an analysis of what should stay in implementors >>>> >>>> Here are the menus in 1.2 and 1.4 >>>> >>> >>> Note that the menu titles are misleading. >>> In previous implementation, 'Implementors of...(m)' did mean >>> implementor of this message or any message called by this method. >> >> I did not pay attention to that because I always type the code but I see now. >> >>> In current implementation, 'Implementors of...(m)' does mean >>> implementor of this message and only this message. >>> Same for 'senders of ...(n)'. >>> >>> That's the main grief I got because this break the browsing chain. >>> If I want to see implementors/senders of a sub message, then I have to: >>> - select the message in text field, then click cmd+m or cmd+n >> >> this is what I do :) >> > > Then also remove implementors/senders from the method list menu... > >>> - if the message is multiple keyword, then this won't work... >> >> We should fix that for any place in the system foo: #yyy to: does not find foo:to: :( >> > > This requires a minimal parsing of surrounding text, maybe shout like > style is enough. > >>> I have to open a finder, copy some text, paste in the finder then >>> click one of the matching methods... >>> That's many more clicks than previous implementation. >> >> Ok we will fix that. >> >> >>> >>> To define a "good" UI you must not only think in term of available >>> feature, other views matter: >>> - homogeneity of presentation / action >>> - number of clicks for accessing a feature >>> - auto-discovery of features rather than implicit knowledge >> >> Yes. >> >>>> Please comment so that we can add what is really used. >>>> As a general comment I would avoid to do everything with a single tool. >>>> >>> >>> Err. I think the contrary. >>> Every such view is a browser with a specific filter on displayed code. >>> The first function of a browser is browsing. >>> Removing browsing capabilities from these views make em become dead >>> ends (look and close). >>> To restore the navigation chain, user must pass thru textual copy/paste. >>> Ubiquitous browsing is a strength of Smalltalk IDE, no? >> >> Yes but do we need spawn subprotocol? and friends. All instances... >> So let us focus on the most 40% most important features and add them to the browsers. >> So there should be a reasonable amount of used functionality. >> >> So let us know what you use most of the time or less and this will be good. >> >> Stef >> > > This reflects my very personnal use for the browsing category : > 5) vital alt+b / alt+N (otherwise I have to type self/print it/select > it/alt+b in Text) > 4) often used: alt+m alt+n (including sub messages) alt+v (my own > right to make mistake) inst var refs/defs (though I also browse it > from text with alt+shift+n for refs) > 3) casually used: alt+h - local implementors/senders - alt+i > inheritance - class var ref/defs > 2) rarely used; none > 1) never used: all the rest > > For actions: > 4) remove method (x) > 3) toggle break on entry (it's not recommended for some kernel UI messages) > 2) fileOut (but in some rare cases this is valuable, it must be able > to filOut the whole list if there is no selection) - change category > 1) all the rest > > But there is a bias, everything accessible thru more... will be less > often used by construction. > > Of course, my flow is a bit different when using OB/RB. > > I'm not biggest OB fan, but I wonder like Marcus if maintaining two > browsers is sustainable. > 1) You have complaints from Lukas because of OB regressions at each upgrade > 2) You get complaints for removed features from end users. > A recipe for maximizing the complaints ;) > While you could integrate OB in dev, core developers would fix OB on > the fly and commit to local Pharo/PharoInbox. > Then Lukas would select/correct/merge available fixes and officialize > them on a new ConfigurationOfOB. > > Nicolas >

Aug. 9, 2011

Re: [Pharo-project] What are the useful operations of implementors/senders that you use

by StÃ©phane Ducasse

On Aug 9, 2011, at 6:50 PM, Gary Chambers wrote: >> Note that the menu titles are misleading. >> In previous implementation, 'Implementors of...(m)' did mean >> implementor of this message or any message called by this method. >> In current implementation, 'Implementors of...(m)' does mean >> implementor of this message and only this message. >> Same for 'senders of ...(n)'. > > I also prefer the choice of actually sent messages to be picked from a list. ok I neer use that because I go faster with the keyboard. But we will added it. > A discontinuity with the standard browsers that is becoming irksome for me... > > For multi keywords it is possible to use the keyboard (both keyboard AND mouse should be available, not just > one or the other) if you select a range that includes all keyword components... Yes that I really want to fix because I hate when it does not work. > I also miss "Browse hierarchy" from implementors, for what it's worth. You will have it all the time with nautilus :) > > Not against improvements to the tools but feedback on changes should be expected! Yes! > > Regards, Gary > >

Aug. 9, 2011

Re: [Pharo-project] Web app security

by laurent laffont

On Mon, Aug 8, 2011 at 1:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > laurent > > are you doing that in a clone of the git vm because it would be good for > traceability? > the repository is here: https://gitorious.org/~laurentlaffont/cogvm/smallharbour Laurent. > > Stef > > On Aug 8, 2011, at 10:09 AM, laurent laffont wrote: > > > Thanks for answers. > > > > What we are currently doing: > > - integrate some vm patches (thanks Mariano :) from netstyle / seaside > hosting which limit file system / socket access > > - try to run hosted images in another account > > > > It seems chrooting each account is not so easy. > > > > Yes, would be nice to make SmallHarbour running on FreeBSD. > > > > Laurent. > > > > > > On Mon, Aug 8, 2011 at 9:37 AM, Miguel Moquillon < > miguel.moquillon(a)gmail.com> wrote: > > If the host of SmallHarbour is running with FreeBSD 8 or Solaris, you can > use the "capabilities" feature to give restrictive priviledges to the > program or to some parts of the program. In short a capability is a pair of > a reference to an object in the system with the rights on that object. You > can allocate to the program a set of capabilities that define the security > environment within which it will run. > > > > Mig > > > > Le 06/08/2011 14:31, Dale Henrichs a Ã©crit : > > > > Laurent, > > > > I think that the best defense is the limited access/rights unix account, > perhaps even a separate unix user per account (to provide isolation between > accounts) ... I think this is what VMware does in in its Cloud Foundry ... > to be completely safe you'd have to turn off the ability to read and write > files and turn off socket access (this is what javascript in the browser > does), but going this far severely limits what you can do in the image ... I > would think that you could screw things down pretty tight just using unix > permissions .... > > > > Dale > > > > ----- Original Message ----- > > | From: "laurent laffont"<laurent.laffont(a)gmail.com> > > | To: "Seaside - developer list"<seaside-dev(a)lists.squeakfoundation.org>, > "An open mailing list to discuss any topics > > | related to an open-source Smalltalk"< > pharo-project(a)lists.gforge.inria.fr> > > | Sent: Saturday, August 6, 2011 3:06:38 AM > > | Subject: [Pharo-project] Web app security > > | > > | Hi, > > | > > | > > | with a public SmallHarbour (public fork of SeasideHosting - > > | smallharbour.org ) people can upload images that do bad things: > > | change filesystem, run commands, .... > > | > > | > > | Actually, what are the ways of securing a server so people can't do > > | bad things ? > > | > > | > > | I'm thinking of: > > | - run the vm/image within a low right unix account > > | - remove dangerous plugins (OSProcess, ?) > > | > > | > > | Can we easily chroot ? > > | > > | > > | what are known solutions ? > > | > > | > > | Laurent. > > > > > > > > > > >

Aug. 9, 2011

Re: [Pharo-project] Polymorph improvements

by Gary Chambers

Just a few more screenshots... http://www.flickr.com/photos/12018791@N06/sets/72157601659393251/with/60259… A few Polymorph tweaks yet to come (AlphaImageMorph with scaling but retained aspect ratio for one...) Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, August 04, 2011 10:46 PM Subject: Re: [Pharo-project] Polymorph improvements I think it's encouraging that the OCR is not in Smalltalk. The fact that Pharo can get between an OCR library and a VB app is a good sign. One could write an OCR system in Smalltalk, but should not _need_ to do so :) Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lorenzo Schiavina [lorenzo(a)edor.it] Sent: Thursday, August 04, 2011 12:02 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Polymorph improvements Thank you Gary, no problem about the fact that OCR is not in ST; as I am working to some projects myself, I know that the problem is to integrate the right tool. Do you mind keeping me informed about the results you reach? Grazie Lorenzo ----- Original Message ----- From: Gary Chambers<mailto:gazzaguru2@btinternet.com> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Sent: Thursday, August 04, 2011 4:20 PM Subject: Re: [Pharo-project] Polymorph improvements Hi Lorenzo, I can't say too much at present but is basically a commercial application for a client for handling postal packages that slip through the rest of their automated processes. So, using a handheld scanner (like MBagger) it gets a scan of the address label, OCRs it and extracts relevant information that can be passed on to their existing (VB) application, along with, say weight from electronic scales etc. Currently we are trialling various 3rd party OCR engines: Abbyy, OmniPage and Tesseract (open source). Of course, I'm making it vastly configurable so there will many potential uses... Sorry if you were actually think that the OCR itself was done by us in Smalltalk ;-) Regards, Gary ----- Original Message ----- From: Lorenzo Schiavina<mailto:lorenzo@edor.it> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Sent: Thursday, August 04, 2011 8:19 AM Subject: Re: [Pharo-project] Polymorph improvements Hi Gary, I have seen from your screenshots that you are working on OCR projecr; can you give my some information about it? Thanks Lorenzo ----- Original Message ----- From: Gary Chambers<mailto:gazzaguru2@btinternet.com> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, August 02, 2011 5:51 PM Subject: Re: [Pharo-project] Polymorph improvements Screenshot of part of project: http://www.flickr.com/photos/12018791@N06/6001799235/in/photostream Regards, Gary ----- Original Message ----- From: Gary Chambers<mailto:gazzaguru2@btinternet.com> To: Pharo Development<mailto:pharo-project@lists.gforge.inria.fr> Sent: Tuesday, August 02, 2011 4:40 PM Subject: [Pharo-project] Polymorph improvements Hi all. I've added an issue with some tweaks/improvements to a few Polymorph classes. http://code.google.com/p/pharo/issues/detail?id=4590 Groupboxes can now have dynamic content (model/getContentSelector based). Abaility to create icon lists via builder/TEasilyThemed. Expander labels now LabelMorphs rather than TextMorphs (can therefore appear as disabled) IncrementalSliderMorphs now honour minWidth/minHeight in layouts Panel morphs allow event based mouse over handling (call to super was missing). Label groups allow for nil labels (equates to empty string) Regards, Gary

Aug. 9, 2011

Re: [Pharo-project] What are the useful operations of implementors/senders that you use

by Nicolas Cellier

2011/8/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Aug 9, 2011, at 6:29 PM, Nicolas Cellier wrote: > >> 2011/8/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> Hi >>> >>> I would like that we do an analysis of what should stay in implementors >>> >>> Here are the menus in 1.2 and 1.4 >>> >> >> Note that the menu titles are misleading. >> In previous implementation, 'Implementors of...(m)' did mean >> implementor of this message or any message called by this method. > > I did not pay attention to that because I always type the code but I see now. > >> In current implementation, 'Implementors of...(m)' does mean >> implementor of this message and only this message. >> Same for 'senders of ...(n)'. >> >> That's the main grief I got because this break the browsing chain. >> If I want to see implementors/senders of a sub message, then I have to: >> - select the message in text field, then click cmd+m or cmd+n > > this is what I do :) > Then also remove implementors/senders from the method list menu... >> - if the message is multiple keyword, then this won't work... > > We should fix that for any place in the system foo: #yyy to: does not find foo:to: :( > This requires a minimal parsing of surrounding text, maybe shout like style is enough. >> Â I have to open a finder, copy some text, paste in the finder then >> click one of the matching methods... >> That's many more clicks than previous implementation. > > Ok we will fix that. > > >> >> To define a "good" UI you must not only think in term of available >> feature, other views matter: >> - homogeneity of presentation / action >> - number of clicks for accessing a feature >> - auto-discovery of features rather than implicit knowledge > > Yes. > >>> Please comment so that we can add what is really used. >>> As a general comment I would avoid to do everything with a single tool. >>> >> >> Err. I think the contrary. >> Every such view is a browser with a specific filter on displayed code. >> The first function of a browser is browsing. >> Removing browsing capabilities from these views make em become dead >> ends (look and close). >> To restore the navigation chain, user must pass thru textual copy/paste. >> Ubiquitous browsing is a strength of Smalltalk IDE, no? > > Yes but do we need spawn subprotocol? and friends. All instances... > So let us focus on the most 40% most important features and add them to the browsers. > So there should be a reasonable amount of used functionality. > > So let us know what you use most of the time or less and this will be good. > > Stef > This reflects my very personnal use for the browsing category : 5) vital alt+b / alt+N (otherwise I have to type self/print it/select it/alt+b in Text) 4) often used: alt+m alt+n (including sub messages) alt+v (my own right to make mistake) inst var refs/defs (though I also browse it from text with alt+shift+n for refs) 3) casually used: alt+h - local implementors/senders - alt+i inheritance - class var ref/defs 2) rarely used; none 1) never used: all the rest For actions: 4) remove method (x) 3) toggle break on entry (it's not recommended for some kernel UI messages) 2) fileOut (but in some rare cases this is valuable, it must be able to filOut the whole list if there is no selection) - change category 1) all the rest But there is a bias, everything accessible thru more... will be less often used by construction. Of course, my flow is a bit different when using OB/RB. I'm not biggest OB fan, but I wonder like Marcus if maintaining two browsers is sustainable. 1) You have complaints from Lukas because of OB regressions at each upgrade 2) You get complaints for removed features from end users. A recipe for maximizing the complaints ;) While you could integrate OB in dev, core developers would fix OB on the fly and commit to local Pharo/PharoInbox. Then Lukas would select/correct/merge available fixes and officialize them on a new ConfigurationOfOB. Nicolas

Aug. 9, 2011

Re: [Pharo-project] [Seaside] Seaside on Pharo-Kernel

by Mariano Martinez Peck

Wow. This is awesome: a working Seaside image in 4.3 MB. On Tue, Aug 9, 2011 at 3:11 PM, Pavel Krivanek <squeak3(a)continentalbrno.cz>wrote: > There is a prepared image: > > > https://ci.lille.inria.fr/pharo/view/Pharo-Kernel/job/Pharo%20Kernel%20Seas… > > -- Pavel > > On Tue, Aug 9, 2011 at 3:03 PM, Sven Van Caekenberghe <sven(a)beta9.be> > wrote: > > Hi Pavel, > > > > This is really cool! > > > > Sven > > > > On 09 Aug 2011, at 12:52, Pavel Krivanek wrote: > > > >> Hi, > >> > >> there's possible to load Seaside to the Pharo-Kernel. > >> > >> 1) Load PharoKernel-Gofer image from CI server > >> ( > https://ci.lille.inria.fr/pharo/view/Pharo-Kernel/job/Pharo%20Kernel%20Gofe… > ) > >> > >> 2) run the image with seaside.st script as an argument. That will > >> create about 4.1 MB image with basic Seaside packages and basic > >> examples. > >> > >> 3) run the image with run.st script (note that starting of the server > >> in the seaside.st script will hang, currently I have no idea why). > >> > >> 4) see if everything works at > http://localhost:8080/examples/examplebrowser > >> > >> Cheers, > >> -- Pavel > >> <run.st><seaside.st>_______________________________________________ > >> seaside mailing list > >> seaside(a)lists.squeakfoundation.org > >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > _______________________________________________ > > seaside mailing list > > seaside(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Mariano http://marianopeck.wordpress.com

Aug. 9, 2011

Re: [Pharo-project] What are the useful operations of implementors/senders that you use

by Gary Chambers

>Note that the menu titles are misleading. >In previous implementation, 'Implementors of...(m)' did mean >implementor of this message or any message called by this method. >In current implementation, 'Implementors of...(m)' does mean >implementor of this message and only this message. >Same for 'senders of ...(n)'. I also prefer the choice of actually sent messages to be picked from a list. A discontinuity with the standard browsers that is becoming irksome for me... For multi keywords it is possible to use the keyboard (both keyboard AND mouse should be available, not just one or the other) if you select a range that includes all keyword components... I also miss "Browse hierarchy" from implementors, for what it's worth. Not against improvements to the tools but feedback on changes should be expected! Regards, Gary

Aug. 9, 2011