December 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] asUrl retrieveContents -> with POST vars

by sergio_101

i know i have done this before, and it's totally escaping me.. i am also not sure if this is the place to ask generic smalltalk questions, so if it's not, please someone let me know.. doing something like: url := 'http://domain/?var1=one&var2=two" url asUrl retrieveContents contents. BUT! i would like to send the vars as POST vars. can i do that with retrieveContents? thanks! -- ---- peace, sergio photographer, journalist, visionary http://www.ThoseOptimizeGuys.com http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

Dec. 17, 2010

Re: [Pharo-project] Issue 3447 in pharo: Do we need to menu entry "Shout Workspace"?

by Levente Uzonyi

On Fri, 17 Dec 2010, pharo(a)googlecode.com wrote: > Status: Accepted > Owner: marcus.denker > Labels: Milestone-1.2-DevImage > > New issue 3447 by marcus.denker: Do we need to menu entry "Shout Workspace"? > http://code.google.com/p/pharo/issues/detail?id=3447 > > The normal workspace seems to have syntax hihjligting alreaday > > Why don't you give ShoutCore (http://source.squeak.org/trunk/ShoutCore-ul.27.mcz ) a try? It works well in Squeak. There's a menu item to enable/disable Shout in the workspace, besides the global preference (not Preference) which applies to all workspaces. It also has the features of ShoutMonticello. It could be developed as a shared package between Pharo and Squeak, like VMMaker or OCompletion. What do you think? Levente

Dec. 17, 2010

Re: [Pharo-project] [Pharo-users] Installing Morphic UI designer in Pharo 1.1

by Mariano Martinez Peck

On Fri, Dec 17, 2010 at 9:05 PM, Charles Monteiro <charles(a)nycsmalltalk.org>wrote: > > Pardon the newbie question but I yet don't have a grip how Squeaker's load > packages , it seems that there are many, many ways of doing so. Hi Charles. We need to be clear in something: indeed, there are too many things to install. So....you can use Installer or Gofer to script your installation in code, but you can still use the normal Monticello Browser. Installer is not loaded in Pharo, so I suggest: a) Use Monticello Browser: open it, new repository -> MetacelloRepository, you search ConfigurationOfDesigner, select it, and then load. Just like lading any other monticello package. Easy. b) Script it. With Gofer, you can do: Gofer new repository: ' http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/MetacelloRepository'; package: 'ConfigurationOfDesigner'; load. Once you did a) or b) evaluate: ConfigurationOfDesigner load. Cheers Mariano > In anycase, > to my immediate need I would like to check out Morphic Designer. I've tried > following the instructions on their web site which are: > > (Installer mc http: > 'http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/') > project: 'MetacelloRepository'; > install: 'ConfigurationOfDesigner'. > ConfigurationOfDesigner load. > > However, on the Pharo 1.1. image under Cog VM, there is no such animal as > an > "Installer", I tried using the Monticello Browser and went fishing for the > package but to no avail. > > thanks in advance > > Charles > www.nycsmalltalk.org > -- > View this message in context: > http://forum.world.st/Installing-Morphic-UI-designer-in-Pharo-1-1-tp3093047… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Dec. 17, 2010

Re: [Pharo-project] Automated VM build server

by laurent laffont

This is really cool Igor. A next step would be to generate packages for major Linux distro (Debian / Ubuntu, Arch, Fedora, ...). Laurent On Fri, Dec 17, 2010 at 9:17 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > In our nearest plans is make an automated (Hudson based) build setup > for Cog and Squeak VMs. > > All files, which used for building an artifacts should be included in > source code repository. > So, most probably i will add the 'hudson-build' dir at same level as > 'platforms', where scripts and configs will be stored. > > Some changes which i going to do: > - all generated code will be removed from version controlled tree. > Instead of it i will add an information, which will be enough > to reproduce the generated code by taking 3 separate config file(s) > > a) image version (or its URL(s) for download) > b) script for loading VMMaker (of concrete version) + all addons like > FFI , FT2 etc etc into image > c) script for generating the source code using VMMaker image > .. > z) tell me if i miss anything here > > With removing generated source code from repo we now can make sure > that any changes in VMMaker (including code generation itself) > can be tested and can be reproduced by build server at any snapshot > version. > Also, we could test & see if VMMaker loads well and can generate code > using different base images. > So, we will instantly know if any changes in compiler, or other layers > of system is breaking VMMaker. > > Because having a years old image where VMMaker works 100%, but at same > time have 100% chances that it > couldn't be loaded (or even if loaded, but can't run correctly) in > latest image is not what i think good practice for > keeping your house clean. > > > So, by getting rid any intermediate artifacts from build chain we > will be able to make sure that: > - VMMaker loads w/o problems in latest/multiple image(s) > - VMMaker works well and can generate code > > That's means that for any newcomer, loading and building VM will be > much less tedious process, and for 99% > of cases it can be fully automated error free process. > > And let me remind our motto: we're not trying to produce perfect > system/setup from first lucky shot. > We slowly but steady crawling towards improved state of art. > > Any comments, ideas and suggestions are welcome. > > -- > Best regards, > Igor Stasenko AKA sig. > >

Dec. 17, 2010

[Pharo-project] Automated VM build server

by Igor Stasenko

In our nearest plans is make an automated (Hudson based) build setup for Cog and Squeak VMs. All files, which used for building an artifacts should be included in source code repository. So, most probably i will add the 'hudson-build' dir at same level as 'platforms', where scripts and configs will be stored. Some changes which i going to do: - all generated code will be removed from version controlled tree. Instead of it i will add an information, which will be enough to reproduce the generated code by taking 3 separate config file(s) a) image version (or its URL(s) for download) b) script for loading VMMaker (of concrete version) + all addons like FFI , FT2 etc etc into image c) script for generating the source code using VMMaker image .. z) tell me if i miss anything here With removing generated source code from repo we now can make sure that any changes in VMMaker (including code generation itself) can be tested and can be reproduced by build server at any snapshot version. Also, we could test & see if VMMaker loads well and can generate code using different base images. So, we will instantly know if any changes in compiler, or other layers of system is breaking VMMaker. Because having a years old image where VMMaker works 100%, but at same time have 100% chances that it couldn't be loaded (or even if loaded, but can't run correctly) in latest image is not what i think good practice for keeping your house clean. So, by getting rid any intermediate artifacts from build chain we will be able to make sure that: - VMMaker loads w/o problems in latest/multiple image(s) - VMMaker works well and can generate code That's means that for any newcomer, loading and building VM will be much less tedious process, and for 99% of cases it can be fully automated error free process. And let me remind our motto: we're not trying to produce perfect system/setup from first lucky shot. We slowly but steady crawling towards improved state of art. Any comments, ideas and suggestions are welcome. -- Best regards, Igor Stasenko AKA sig.

Dec. 17, 2010

Re: [Pharo-project] [Vm-dev] Re: Issue 3446 in pharo: VMMakerTool load config buttondoesn't work

by David T. Lewis

On Fri, Dec 17, 2010 at 06:39:33PM +0100, Levente Uzonyi wrote: > > On Fri, 17 Dec 2010, Javier Pim?s wrote: > > >OK, if I'm correct the 3449 issue is fixed and integrated now. So how do we > >solve this one? Because the method lays on VMMakerTool's code, for squeak. > >Maybe we can add a line to ConfigurationOfVMMaker>>#fixVMMakerForPharo like > >this: <snip> > >It's a bit of a dirty hack, maybe there's a cleaner way. What do you think? > > No need to do dirty hacks, just communicate your needs properly. Ask David > to update the method. Squeak (since 3.9) also implements UIManager >> > #chooseFileMatching:label:. Note that the name of this method is a bit > misleading. The first argument is a list of "file extensions", not a list > of patterns. So this should work in both Squeak and Pharo: > > fileResult := UIManager default > chooseFileMatching: #('config') > label: 'Select VMMaker configuration...'. > > Since fileResult is a string that contains the full path, the variable > "file" is not necessary anymore. This is in VMMaker-dtl.211. The #saveConfig method had a similar problem, so I changed it to use UIManager>>request:initialAnswer: Both methods should work on Squeak/Pharo now. Thanks, Dave

Dec. 17, 2010

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by Philippe Marschall

On 15.12.2010 17:04, Sven Van Caekenberghe wrote: > I am pleased to report another milestone was reached in the Zn project. > > The default implementation for an HTTP Server is now a multi-threaded (forking) keep-alive implementation called ZnMultiThreadedServer. It passes my initial concurrent load tests. ZnServer is now a facade. This means that all features (test server, static file server, monticello server, seaside adaptor, as well as all unit tests) are now using the new code. > > In addition, several useful features were added to the servers, including logging and lastRequest/lastResponse debugging hooks. Extra handlers were added to ZnDefaultServerDelegate (favicon, benchmark, random) which double as examples. > > Next up will be some benchmarking and optimalization. As always, users/testers are most welcome. This is with the AJPFastRequestHandler from the AJP-Benchmark package from http://www.squeaksource.com/ajp (there are no dependencies to AJP). ab -k -c 10 -n 10000 http://127.0.0.1:8080/fast This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 127.0.0.1 (be patient) Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests Completed 10000 requests Finished 10000 requests Server Software: Zinc Server Hostname: 127.0.0.1 Server Port: 8080 Document Path: /fast Document Length: 16294 bytes Concurrency Level: 10 Time taken for tests: 5.624 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Keep-Alive requests: 10000 Total transferred: 164560000 bytes HTML transferred: 162940000 bytes Requests per second: 1778.08 [#/sec] (mean) Time per request: 5.624 [ms] (mean) Time per request: 0.562 [ms] (mean, across all concurrent requests) Transfer rate: 28574.28 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 0 6 17.1 1 155 Waiting: 0 6 17.1 0 155 Total: 0 6 17.1 1 155 Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 15 95% 44 98% 70 99% 89 100% 155 (longest request) Not too shabby. Cheers Philippe

Dec. 17, 2010

Re: [Pharo-project] Graph library in Smalltalk - Need for advices

by YossiDM

JGraphT worked alright in what I tried against in the past, but it won't scale to huge heights like most libs without major tweaking or a graph DB backing it along with some serious threading. Just to throw in a few others I've used, but not with Smalltalk: * https://software.sandia.gov/trac/mtgl MTGL * http://lemon.cs.elte.hu/trac/lemon LEMON * .NET http://quickgraph.codeplex.com/ Quickgraph /Graph# * http://igraph.sourceforge.net/introduction.html iGraph * http://snap-graph.sourceforge.net/ SNAP Of the above, I've had some of the best experience with LEMON in terms of scale and speed for real-world usage. Unfortunately, none of these libraries include everything you'd want, so at some point you will have to roll some stuff yourself. That's been my experience at least. Some Graph or Graph-like Databases (tend to have some algorithm libs as well): * http://www.infinitegraph.com InfiniteGraph (this runs on Objectivity underneath the covers which has a Smalltalk impl) * http://www.neo4j.org neo4j * http://www.kobrix.com/hgdb.jsp HyperGraphDB Some related useful items for dealing with large sets and graphs when you are thinking about performance and/or parallel processing: * http://gauss.cs.ucsb.edu/~aydin/doc/html/index.html Combinatorial BLAS * http://www.semanticdesigns.com/Products/PARLANSE/ PARLANSE * http://research.microsoft.com/en-us/projects/dryadlinq/ DRYAD LINQ FYI, I would strongly recommend against using Ruby for anything with graphs except as a simple client lib. I spent a lot of time on this before and it simply does not scale or perform to anything beyond very simple cases, and the memory footprint in a real app becomes horrendous. We had to tweak the hell out of some libs to get anything decent and even then we ended up writing stacks of C to compensate. If you're just dealing with 100 vertex undirected graphs, then it works great. It's honestly the fault of a lot of the libs rather than the language, but nonetheless be warned. -- View this message in context: http://forum.world.st/Graph-library-in-Smalltalk-Need-for-advices-tp3092747… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 17, 2010

Re: [Pharo-project] Issue 3446 in pharo: VMMakerTool load config buttondoesn't work

by Gary Chambers

Misleading indeed, probably why I had it that way initially. Obviously this will no longer work with the earlier fix. Guess it is time to decide whether we want patterns or extensions. I suggest we have another UIManager method with extensions in addition to the (semantically) fixed patterns one (that is more flexible). Regards, Gary ----- Original Message ----- From: "Levente Uzonyi" <leves(a)elte.hu> To: <Pharo-project(a)lists.gforge.inria.fr> Cc: <vm-dev(a)lists.squeakfoundation.org> Sent: Friday, December 17, 2010 5:39 PM Subject: Re: [Pharo-project] Issue 3446 in pharo: VMMakerTool load config buttondoesn't work On Fri, 17 Dec 2010, Javier PimÃ¡s wrote: > OK, if I'm correct the 3449 issue is fixed and integrated now. So how do > we > solve this one? Because the method lays on VMMakerTool's code, for squeak. > Maybe we can add a line to ConfigurationOfVMMaker>>#fixVMMakerForPharo > like > this: > > (Smalltalk at: #VMMakerTool) compile: > 'loadConfig > | fileResult file | > fileResult := UIManager default chooseFileMatching: #(''*.config'') label: > ''Select > VMMaker configuration...''. > fileResult > ifNotNil: [file := fileResult. > [vmMaker := VMMaker forConfigurationFile: file. > vmMaker logger: logger. > vmMaker platformDirectory] > on: Error > do: [self inform: ''Possible problem with path settings or platform > name?'']. > self updateAllViews]' > > > It's a bit of a dirty hack, maybe there's a cleaner way. What do you > think? No need to do dirty hacks, just communicate your needs properly. Ask David to update the method. Squeak (since 3.9) also implements UIManager >> #chooseFileMatching:label:. Note that the name of this method is a bit misleading. The first argument is a list of "file extensions", not a list of patterns. So this should work in both Squeak and Pharo: fileResult := UIManager default chooseFileMatching: #('config') label: 'Select VMMaker configuration...'. Since fileResult is a string that contains the full path, the variable "file" is not necessary anymore. Levente > > Regards, > Javier. > > On Fri, Dec 17, 2010 at 8:35 AM, Gary Chambers > <gazzaguru2(a)btinternet.com>wrote: > >> It seems the implementation in MorphicUIManager uses the patterns >> as extensions. >> >> So >> fileResult := UIManager default chooseFileMatching: #('config') label: >> 'Select >> VMMaker configuration...'. >> >> would work. >> >> However, that misses the meaning of patterns. >> I've raised issue >> http://code.google.com/p/pharo/issues/detail?id=3449with change set >> attached... >> >> Regards, Gary >> >> ----- Original Message ----- From: <pharo(a)googlecode.com> >> To: <pharo-project(a)lists.gforge.inria.fr> >> Sent: Friday, December 17, 2010 4:21 AM >> Subject: [Pharo-project] Issue 3446 in pharo: VMMakerTool load config >> buttondoesn't work >> >> >> >> Status: New >>> Owner: ---- >>> >>> New issue 3446 by elpochodelagente: VMMakerTool load config button >>> doesn't >>> work >>> http://code.google.com/p/pharo/issues/detail?id=3446 >>> >>> Pharo image: dev 1.1.1 >>> Pharo core version: Pharo-1.1-11411 >>> Virtual machine used: custom linux, allmost latest VMMaker, classic (not >>> cog) >>> Class browser used if applicable: OBSystemBrowserAdaptor >>> >>> Steps to reproduce: >>> 1. Load VMMaker with >>> 2. Open the VMMakerTool with: "VMMakerTool openInWorld" >>> 3. Push load config button, you get an error message >>> >>> The problem is that VMMaker tool makes use of StandardFileDialog, which >>> isn't present in Pharo anymore. The method that raises the error is >>> >>> VMMakerTool>>#loadConfig >>> | fileResult file | >>> fileResult := (StandardFileMenu oldFileMenu: FileDirectory default >>> withPattern: '*.config') startUpWithCaption: 'Select VMMaker >>> configuration...'. >>> fileResult >>> ifNotNil: [ >>> file := fileResult directory fullNameFor: fileResult name. >>> [ >>> vmMaker := VMMaker forConfigurationFile: file. >>> vmMaker logger: logger. >>> vmMaker platformDirectory >>> ] >>> on: Error >>> do: [self inform: 'Possible problem with path settings or >>> platform name?']. >>> self updateAllViews] >>> >>> >>> Changing >>> >>> fileResult := (StandardFileMenu oldFileMenu: FileDirectory default >>> withPattern: '*.config') startUpWithCaption: 'Select VMMaker >>> configuration...'. >>> >>> for >>> >>> fileResult := UIManager default chooseFileMatching: nil label: 'Select >>> VMMaker configuration...'. >>> >>> and >>> >>> file := fileResult directory fullNameFor: fileResult name. >>> >>> for >>> >>> file := fileResult >>> >>> Fixes it almost completely. It would be better to use >>> chooseFileMatching: >>> #('*.config') but it didn't work well. >>> >>> >>> >>> >> >> > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires >

Dec. 17, 2010

Re: [Pharo-project] [Vm-dev] Re: Issue 3446 in pharo: VMMakerTool load config buttondoesn't work

by Javier PimÃ¡s

2010/12/17 Levente Uzonyi <leves(a)elte.hu> > > On Fri, 17 Dec 2010, Javier PimÃ¡s wrote: > > OK, if I'm correct the 3449 issue is fixed and integrated now. So how do >> we >> solve this one? Because the method lays on VMMakerTool's code, for squeak. >> Maybe we can add a line to ConfigurationOfVMMaker>>#fixVMMakerForPharo >> like >> this: >> >> (Smalltalk at: #VMMakerTool) compile: >> 'loadConfig >> | fileResult file | >> fileResult := UIManager default chooseFileMatching: #(''*.config'') label: >> ''Select >> VMMaker configuration...''. >> fileResult >> ifNotNil: [file := fileResult. >> [vmMaker := VMMaker forConfigurationFile: file. >> vmMaker logger: logger. >> vmMaker platformDirectory] >> on: Error >> do: [self inform: ''Possible problem with path settings or platform >> name?'']. >> self updateAllViews]' >> >> >> It's a bit of a dirty hack, maybe there's a cleaner way. What do you >> think? >> > > No need to do dirty hacks, just communicate your needs properly. Ask David > to update the method. Squeak (since 3.9) also implements UIManager >> > #chooseFileMatching:label:. Note that the name of this method is a bit > misleading. The first argument is a list of "file extensions", not a list of > patterns. So this should work in both Squeak and Pharo: > > fileResult := UIManager default > chooseFileMatching: #('config') > label: 'Select VMMaker configuration...'. > > Since fileResult is a string that contains the full path, the variable > "file" is not necessary anymore. > > Excelent! Many thanks for the redirect! javier > > Levente > > >> Regards, >> Javier. >> >> On Fri, Dec 17, 2010 at 8:35 AM, Gary Chambers <gazzaguru2(a)btinternet.com >> >wrote: >> >> It seems the implementation in MorphicUIManager uses the patterns >>> as extensions. >>> >>> So >>> fileResult := UIManager default chooseFileMatching: #('config') label: >>> 'Select >>> VMMaker configuration...'. >>> >>> would work. >>> >>> However, that misses the meaning of patterns. >>> I've raised issue >>> http://code.google.com/p/pharo/issues/detail?id=3449with change set >>> attached... >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: <pharo(a)googlecode.com> >>> To: <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Friday, December 17, 2010 4:21 AM >>> Subject: [Pharo-project] Issue 3446 in pharo: VMMakerTool load config >>> buttondoesn't work >>> >>> >>> >>> Status: New >>> >>>> Owner: ---- >>>> >>>> New issue 3446 by elpochodelagente: VMMakerTool load config button >>>> doesn't >>>> work >>>> http://code.google.com/p/pharo/issues/detail?id=3446 >>>> >>>> Pharo image: dev 1.1.1 >>>> Pharo core version: Pharo-1.1-11411 >>>> Virtual machine used: custom linux, allmost latest VMMaker, classic (not >>>> cog) >>>> Class browser used if applicable: OBSystemBrowserAdaptor >>>> >>>> Steps to reproduce: >>>> 1. Load VMMaker with >>>> 2. Open the VMMakerTool with: "VMMakerTool openInWorld" >>>> 3. Push load config button, you get an error message >>>> >>>> The problem is that VMMaker tool makes use of StandardFileDialog, which >>>> isn't present in Pharo anymore. The method that raises the error is >>>> >>>> VMMakerTool>>#loadConfig >>>> | fileResult file | >>>> fileResult := (StandardFileMenu oldFileMenu: FileDirectory default >>>> withPattern: '*.config') startUpWithCaption: 'Select VMMaker >>>> configuration...'. >>>> fileResult >>>> ifNotNil: [ >>>> file := fileResult directory fullNameFor: fileResult name. >>>> [ >>>> vmMaker := VMMaker forConfigurationFile: file. >>>> vmMaker logger: logger. >>>> vmMaker platformDirectory >>>> ] >>>> on: Error >>>> do: [self inform: 'Possible problem with path settings or >>>> platform name?']. >>>> self updateAllViews] >>>> >>>> >>>> Changing >>>> >>>> fileResult := (StandardFileMenu oldFileMenu: FileDirectory default >>>> withPattern: '*.config') startUpWithCaption: 'Select VMMaker >>>> configuration...'. >>>> >>>> for >>>> >>>> fileResult := UIManager default chooseFileMatching: nil label: 'Select >>>> VMMaker configuration...'. >>>> >>>> and >>>> >>>> file := fileResult directory fullNameFor: fileResult name. >>>> >>>> for >>>> >>>> file := fileResult >>>> >>>> Fixes it almost completely. It would be better to use >>>> chooseFileMatching: >>>> #('*.config') but it didn't work well. >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> > > -- Javier PimÃ¡s Ciudad de Buenos Aires

Dec. 17, 2010