Re: [Pharo-project] Alternative to MC for upload?
In honor of Stef, let's make this *really* simple. The pieces for what I want to do MUST exist; I just don't see how to make it happen. So let's say I have GiveThisToStef.mcz on my drive, and I have checked, and rechecked that it is clean and releasable. Can I use an FTP client or some other command line tool to put that in the in box? That way, the code will be where everyone wants it (vs. just attached to email here), and I won't have to worry about what MC might be doing that I didn't anticipate. I know MC can do the whole thing - trouble is it once did something I didn't expect, and I can't have that (legal exposure). I want a clear wall that I deliberately penetrate when I have something to share - it's that simple. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Nick Ager [nick.a...@gmail.com] Sent: Monday, February 06, 2012 2:04 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Alternative to MC for upload? Hi, For private code I began by using an ftp repository then switched to a WebDAV server, With a private WebDAV server you can use Monticello, Gofer etc as though you are using squeak-source - though without a front-end. If you want a front-end there is squeak-source 3 [1] Nick [1] http://ss3.gemstone.com/ss/ss3.html/Overview On 5 February 2012 18:03, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: You're not daft; I'm simply looking for suggestions; yours counts :) From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Göran Krampe [go...@krampe.semailto:go...@krampe.se] Sent: Sunday, February 05, 2012 12:12 PM To: pharo-project@lists.gforge.inria.frmailto:pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Alternative to MC for upload? On 02/05/2012 12:30 PM, Schwab,Wilhelm K wrote: Hello all, I have a fair amount of code that I can't/don't dare release because it involves intellectual property that I do not own, and access under non-disclosure agreements (some of which are silly, but need to be respected regardless). None of that code it is relevant to you (unless you do heart surgery at home), but I need to keep it separate from things like GSL, PLplot, FFI tweaks, etc., that should interest the community. In the past, I've saved to http repositories and been surprised at things (fortunately, nothing toxic) that were released w/o my intent. Squeak Source long since lost the code in question, but it put a fear of MC in me. Is there a way to use gofer or something else to send specific .mcz files that I want to make available? Some other tool? Perhaps I am daft - but why don't you use either local directories for those packages or a private ftp server (like I do)? I use pure-ftpd which is really nice because it can easily map specific users to specific home directories. regards, Göran
Re: [Pharo-project] pharo vision
This is sounding pretty good. When can we have it? :) One thing: re-using existing libraries and tools is generally a good thing (GSL PLplot, gnuplot, etc. are powerful), but *sometimes* one is better off rewriting to gain flexibility or some other freedom. Maybe it is mostly a Windows thing, but I recall becoming radically happier when I ditched MS' http technology for something that just did some text transfer and actually, W*O*R*K*E*D. Between thread affinities, completely uninspired error handling/recovery, and generally stupid design, the MS code was more trouble than it was worth. It was intertwingled with Internet Explorer in ways that were simply not healthy... We should be able to reinvent or reuse with equal smoothness, and do the right thing in each case. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of S Krish [krishnamachari.sudha...@gmail.com] Sent: Monday, February 06, 2012 12:31 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] pharo vision My two cents: Pharo Roadmap: Should be a clean, basic kernel, rockstable, IDE that is guaranteed to work most efficiently with its base library, compiler. Perfect and simplest kernel. I do consider a perfect FFI, Collections, Streams ( including File/ Socket ), String, Graphics, UI widget/canvas library as base and some more that are basics. FFI that is non-blocking/ callback supported through all major platforms. Optimization for all the collections hierarchy, clean FS including networking support, cleaner , Morphic widgets.. The IDE that works and never crashes for all newbie interactions, that should be glitch free and offer failsafe error handlers at the image level if something does go wrong to handle it cleanly... Rest everything is secondary or even tertiary at this point. Source Code mgmt: this is an important top level package, ideal if its an external package. No other platform comes loaded with an IDE, debugger, source code mgmt as default.. It is the base kernel + IDE + external pacakges.. Gives options to uses in future to switch between MC/ Git/ SVN as they may want it to be without the noise/ extras. Rich libraries Seriously should we be reinventing the wheel, unless there is luxury in future to do so. Reusing all that we can from all other platfoms: C libs, Java, Ruby, Python.. etc.. is perfectly fine. For turtles down the line, we should simply have any contributor give an interface package for minimal and extensible connection to say: Reports, DBMS, ... etc using something that works viz: C interfaces, XMLRPC ( SOAP aint the best..!) and perhaps some other custom connector through plugin mechanism as is done for DBXSqueak... UI frameworks: This too should remain an outside package not built in.. there can be many lines of thought and processes.. and each one completely acceptable from their usage/ view standpoint.. Usable Pharo base : ( Base: Excellent Kernel + Morphic ) + Source Code Mgmt Package Usable Pharo Web : Pharo Base + Seaside Make a separate workspace/ area for Pharo Foundation supported / approved secondary package, so that download from there is more guaranteed than other user contributed areas/ projects people host/ support on their own. On Sun, Feb 5, 2012 at 11:13 PM, Philippe Marschall kus...@gmx.netmailto:kus...@gmx.net wrote: On 30.01.2012 09:24, Stéphane Ducasse wrote: OK, so here's my take. I try to not turn this into a wish list. Rich libraries While I obviously agree that rich libraries are valuable I believe it's important to have clear guidelines to what should be part of Pharo and what not. In one extreme I could have everything from SqS be part of Pharo. I don't think this is the idea. You don't want to have the same discussion for every library whether it should be part of Pharo. FFI First I think we need to have a problem statement. We want to be able to use libraries written in C from Pharo. We don't implement them in Pharo because we don't have the resources to develop them or Pharo is unsuited for the task. This sucks because it's no longer turtles all the way down but better than nothing. Since blocking C calls block the entire VM until the call returns we need to have threaded-FFI. Yes, I do think that callbacks should be mentioned here. Currently the situation as I understand it is: - use FFI for call-outs - use Alien for call-backs - use NativeBoost for faster callouts? portable plugins? It would be really nice to have a better, more integrated solution here. If that results in something that's more than a one liner for a C call that's fine with me. 64 bit I think it's important to make a distinction between 64bit images and 64 bit VMs. 64 bit VMs Unless you on a small device current systems are 64bit. While most of them offer some sort of way for running 32bit applications this
Re: [Pharo-project] Creating a file with FS
On 2012-02-05, at 16:16, stephane ducasse wrote: Hi FS users I'm puzzled by FS api. I want to create a file in a directory so I did | wk | wk := FSFilesystem disk workingDirectory. (wk / 'CSS2') ensureDirectory worked Now I looked at ensureFile and I do not understand the code ensureFile Create if necessary a file for the receiver. self writeStream close. Because I would like to be able to write in the file and now I do not see why closing it is good. ensureFile makes sense: - it creates an _empty_ file - it still returns the FSReference... what you want is the following I guess: (wk / 'foo') writeStreamDo: [ :s| s 'bar' ]. since that will - create also create a new file. - ensure closing the stream FSReferencewriteStreamDo: doBlock ifPresent: presentBlock Create a file if not present and execute doBlock (with a stream) as argument, if the file is present execute the presentBlock. ^ self isFile ifTrue: [ presentBlock value ] ifFalse: [ self writeStreamDo: doBlock ] FSReferencewriteStreamIfPresent: presentBlock Return a writestream on the receiver if it does not already exist or execute the presentBlock with no argument ^ self isFile ifTrue: [ presentBlock value ] ifFalse: [ self writeStream ] I do not get why we do not get as argument to the presentBlock the file itself? indeed, a [... cull: self] might make sense here :) I added method comments…. as usual. :( Camillo could you have a look at such comments and commit them? I published the package to the fs package. Would be good to cross check and that I add it in 1.4 will do FSReference-streams.st Stef
Re: [Pharo-project] Alternative to MC for upload?
Schwab,Wilhelm K wrote: In honor of Stef, let's make this *really* simple. The pieces for what I want to do MUST exist; I just don't see how to make it happen. So let's say I have GiveThisToStef.mcz on my drive, and I have checked, and rechecked that it is clean and releasable. Can I use an FTP client or some other command line tool to put that in the in box? If that inbox was a ftp repository then you would be able to use a separate ftp client to upload to it. However most of the current repositories your want to deal with are http repositories that wont work with your ftp client. You might try curl (http://linux.about.com/od/commands/l/blcmdl1_curl.htm) and play around with authentication schemes to find one that matches squeaksource. However just to double-check... I understand your not wanting to use the Save button to store directly to a remote repository because it is hard to undo accidents. However have you specifically discounted the Copy button on the Repository Inspector. Try this proposed workflow... 1. In Monticello Browser, in the left-pane select your package. In the right-pane select the local-package-cache. 2. Unzip the created GiveThisToStef.1.mcz and undertake due-diligence-scan for NDA code. If all okay 3. In Monticello Browser, in the right-pane select your local-package-cache, click the Open button. 4. Select the GiveThisToStef.1.mcz. Click the Copy button. Select the remote repository to upload to. This seems to provide everything with you need to avoid surprises. That way, the code will be where everyone wants it (vs. just attached to email here), and I won't have to worry about what MC might be doing that I didn't anticipate. I know MC can do the whole thing - trouble is it once did something I didn't expect, and I can't have that (legal exposure). I want a clear wall that I deliberately penetrate when I have something to share - it's that simple. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Nick Ager [nick.a...@gmail.com] Sent: Monday, February 06, 2012 2:04 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Alternative to MC for upload? Hi, For private code I began by using an ftp repository then switched to a WebDAV server, With a private WebDAV server you can use Monticello, Gofer etc as though you are using squeak-source - though without a front-end. If you want a front-end there is squeak-source 3 [1] Nick [1] http://ss3.gemstone.com/ss/ss3.html/Overview On 5 February 2012 18:03, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: You're not daft; I'm simply looking for suggestions; yours counts :) From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Göran Krampe [go...@krampe.semailto:go...@krampe.se] Sent: Sunday, February 05, 2012 12:12 PM To: pharo-project@lists.gforge.inria.frmailto:pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Alternative to MC for upload? On 02/05/2012 12:30 PM, Schwab,Wilhelm K wrote: Hello all, I have a fair amount of code that I can't/don't dare release because it involves intellectual property that I do not own, and access under non-disclosure agreements (some of which are silly, but need to be respected regardless). None of that code it is relevant to you (unless you do heart surgery at home), but I need to keep it separate from things like GSL, PLplot, FFI tweaks, etc., that should interest the community. In the past, I've saved to http repositories and been surprised at things (fortunately, nothing toxic) that were released w/o my intent. Squeak Source long since lost the code in question, but it put a fear of MC in me. Is there a way to use gofer or something else to send specific .mcz files that I want to make available? Some other tool? Perhaps I am daft - but why don't you use either local directories for those packages or a private ftp server (like I do)? I use pure-ftpd which is really nice because it can easily map specific users to specific home directories. regards, Göran
Re: [Pharo-project] Alternative to MC for upload?
http://lmgtfy.com/?q=webdav+command-line http://stackoverflow.com/questions/1205101/command-line-utility-for-webdav-upload On 6 February 2012 07:59, Schwab,Wilhelm K bsch...@anest.ufl.edu wrote: In honor of Stef, let's make this *really* simple. The pieces for what I want to do MUST exist; I just don't see how to make it happen. So let's say I have GiveThisToStef.mcz on my drive, and I have checked, and rechecked that it is clean and releasable. Can I use an FTP client or some other command line tool to put that in the in box? That way, the code will be where everyone wants it (vs. just attached to email here), and I won't have to worry about what MC might be doing that I didn't anticipate. I know MC can do the whole thing - trouble is it once did something I didn't expect, and I can't have that (legal exposure). I want a clear wall that I deliberately penetrate when I have something to share - it's that simple. Bill -- *From:* pharo-project-boun...@lists.gforge.inria.fr [ pharo-project-boun...@lists.gforge.inria.fr] on behalf of Nick Ager [ nick.a...@gmail.com] *Sent:* Monday, February 06, 2012 2:04 AM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Alternative to MC for upload? Hi, For private code I began by using an ftp repository then switched to a WebDAV server, With a private WebDAV server you can use Monticello, Gofer etc as though you are using squeak-source - though without a front-end. If you want a front-end there is squeak-source 3 [1] Nick [1] http://ss3.gemstone.com/ss/ss3.html/Overview On 5 February 2012 18:03, Schwab,Wilhelm K bsch...@anest.ufl.edu wrote: You're not daft; I'm simply looking for suggestions; yours counts :) From: pharo-project-boun...@lists.gforge.inria.fr [ pharo-project-boun...@lists.gforge.inria.fr] on behalf of Göran Krampe [ go...@krampe.se] Sent: Sunday, February 05, 2012 12:12 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Alternative to MC for upload? On 02/05/2012 12:30 PM, Schwab,Wilhelm K wrote: Hello all, I have a fair amount of code that I can't/don't dare release because it involves intellectual property that I do not own, and access under non-disclosure agreements (some of which are silly, but need to be respected regardless). None of that code it is relevant to you (unless you do heart surgery at home), but I need to keep it separate from things like GSL, PLplot, FFI tweaks, etc., that should interest the community. In the past, I've saved to http repositories and been surprised at things (fortunately, nothing toxic) that were released w/o my intent. Squeak Source long since lost the code in question, but it put a fear of MC in me. Is there a way to use gofer or something else to send specific .mcz files that I want to make available? Some other tool? Perhaps I am daft - but why don't you use either local directories for those packages or a private ftp server (like I do)? I use pure-ftpd which is really nice because it can easily map specific users to specific home directories. regards, Göran
Re: [Pharo-project] Alternative to MC for upload?
curl -T GiveThisToStef.mcz http://www.squeaksource.com/PharoInbox On 6 February 2012 08:35, Nick Ager nick.a...@gmail.com wrote: http://lmgtfy.com/?q=webdav+command-line http://stackoverflow.com/questions/1205101/command-line-utility-for-webdav-upload On 6 February 2012 07:59, Schwab,Wilhelm K bsch...@anest.ufl.edu wrote: In honor of Stef, let's make this *really* simple. The pieces for what I want to do MUST exist; I just don't see how to make it happen. So let's say I have GiveThisToStef.mcz on my drive, and I have checked, and rechecked that it is clean and releasable. Can I use an FTP client or some other command line tool to put that in the in box? That way, the code will be where everyone wants it (vs. just attached to email here), and I won't have to worry about what MC might be doing that I didn't anticipate. I know MC can do the whole thing - trouble is it once did something I didn't expect, and I can't have that (legal exposure). I want a clear wall that I deliberately penetrate when I have something to share - it's that simple. Bill -- *From:* pharo-project-boun...@lists.gforge.inria.fr [ pharo-project-boun...@lists.gforge.inria.fr] on behalf of Nick Ager [ nick.a...@gmail.com] *Sent:* Monday, February 06, 2012 2:04 AM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Alternative to MC for upload? Hi, For private code I began by using an ftp repository then switched to a WebDAV server, With a private WebDAV server you can use Monticello, Gofer etc as though you are using squeak-source - though without a front-end. If you want a front-end there is squeak-source 3 [1] Nick [1] http://ss3.gemstone.com/ss/ss3.html/Overview On 5 February 2012 18:03, Schwab,Wilhelm K bsch...@anest.ufl.edu wrote: You're not daft; I'm simply looking for suggestions; yours counts :) From: pharo-project-boun...@lists.gforge.inria.fr [ pharo-project-boun...@lists.gforge.inria.fr] on behalf of Göran Krampe [ go...@krampe.se] Sent: Sunday, February 05, 2012 12:12 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Alternative to MC for upload? On 02/05/2012 12:30 PM, Schwab,Wilhelm K wrote: Hello all, I have a fair amount of code that I can't/don't dare release because it involves intellectual property that I do not own, and access under non-disclosure agreements (some of which are silly, but need to be respected regardless). None of that code it is relevant to you (unless you do heart surgery at home), but I need to keep it separate from things like GSL, PLplot, FFI tweaks, etc., that should interest the community. In the past, I've saved to http repositories and been surprised at things (fortunately, nothing toxic) that were released w/o my intent. Squeak Source long since lost the code in question, but it put a fear of MC in me. Is there a way to use gofer or something else to send specific .mcz files that I want to make available? Some other tool? Perhaps I am daft - but why don't you use either local directories for those packages or a private ftp server (like I do)? I use pure-ftpd which is really nice because it can easily map specific users to specific home directories. regards, Göran
Re: [Pharo-project] pharo vision
Obligatory You mis-understand the purpose of Microsoft's libraries, which is to suck up several years of potentially competing developer resources before Microsoft change the game by throwing everything away so you are playing catch up again. -ben Schwab,Wilhelm K wrote: This is sounding pretty good. When can we have it? :) One thing: re-using existing libraries and tools is generally a good thing (GSL PLplot, gnuplot, etc. are powerful), but *sometimes* one is better off rewriting to gain flexibility or some other freedom. Maybe it is mostly a Windows thing, but I recall becoming radically happier when I ditched MS' http technology for something that just did some text transfer and actually, W*O*R*K*E*D. Between thread affinities, completely uninspired error handling/recovery, and generally stupid design, the MS code was more trouble than it was worth. It was intertwingled with Internet Explorer in ways that were simply not healthy... We should be able to reinvent or reuse with equal smoothness, and do the right thing in each case. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of S Krish [krishnamachari.sudha...@gmail.com] Sent: Monday, February 06, 2012 12:31 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] pharo vision My two cents: Pharo Roadmap: Should be a clean, basic kernel, rockstable, IDE that is guaranteed to work most efficiently with its base library, compiler. Perfect and simplest kernel. I do consider a perfect FFI, Collections, Streams ( including File/ Socket ), String, Graphics, UI widget/canvas library as base and some more that are basics. FFI that is non-blocking/ callback supported through all major platforms. Optimization for all the collections hierarchy, clean FS including networking support, cleaner , Morphic widgets.. The IDE that works and never crashes for all newbie interactions, that should be glitch free and offer failsafe error handlers at the image level if something does go wrong to handle it cleanly... Rest everything is secondary or even tertiary at this point. Source Code mgmt: this is an important top level package, ideal if its an external package. No other platform comes loaded with an IDE, debugger, source code mgmt as default.. It is the base kernel + IDE + external pacakges.. Gives options to uses in future to switch between MC/ Git/ SVN as they may want it to be without the noise/ extras. Rich libraries Seriously should we be reinventing the wheel, unless there is luxury in future to do so. Reusing all that we can from all other platfoms: C libs, Java, Ruby, Python.. etc.. is perfectly fine. For turtles down the line, we should simply have any contributor give an interface package for minimal and extensible connection to say: Reports, DBMS, ... etc using something that works viz: C interfaces, XMLRPC ( SOAP aint the best..!) and perhaps some other custom connector through plugin mechanism as is done for DBXSqueak... UI frameworks: This too should remain an outside package not built in.. there can be many lines of thought and processes.. and each one completely acceptable from their usage/ view standpoint.. Usable Pharo base : ( Base: Excellent Kernel + Morphic ) + Source Code Mgmt Package Usable Pharo Web : Pharo Base + Seaside Make a separate workspace/ area for Pharo Foundation supported / approved secondary package, so that download from there is more guaranteed than other user contributed areas/ projects people host/ support on their own. On Sun, Feb 5, 2012 at 11:13 PM, Philippe Marschall kus...@gmx.netmailto:kus...@gmx.net wrote: On 30.01.2012 09:24, Stéphane Ducasse wrote: OK, so here's my take. I try to not turn this into a wish list. Rich libraries While I obviously agree that rich libraries are valuable I believe it's important to have clear guidelines to what should be part of Pharo and what not. In one extreme I could have everything from SqS be part of Pharo. I don't think this is the idea. You don't want to have the same discussion for every library whether it should be part of Pharo. FFI First I think we need to have a problem statement. We want to be able to use libraries written in C from Pharo. We don't implement them in Pharo because we don't have the resources to develop them or Pharo is unsuited for the task. This sucks because it's no longer turtles all the way down but better than nothing. Since blocking C calls block the entire VM until the call returns we need to have threaded-FFI. Yes, I do think that callbacks should be mentioned here. Currently the situation as I understand it is: - use FFI for call-outs - use Alien for call-backs - use NativeBoost for faster callouts? portable plugins? It would be really nice to have a better, more integrated solution here. If that results in something that's more than a
Re: [Pharo-project] Alternative to MC for upload?
Ok, this copy button thing is a new idea. Will investigate... I'm also going to look at MC code for the part that does the actual save. There must be a way to script that to do exactly what I want - no worries and code where it should be. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Ben Coman [b...@openinworld.com] Sent: Monday, February 06, 2012 3:35 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Alternative to MC for upload? Schwab,Wilhelm K wrote: In honor of Stef, let's make this *really* simple. The pieces for what I want to do MUST exist; I just don't see how to make it happen. So let's say I have GiveThisToStef.mcz on my drive, and I have checked, and rechecked that it is clean and releasable. Can I use an FTP client or some other command line tool to put that in the in box? If that inbox was a ftp repository then you would be able to use a separate ftp client to upload to it. However most of the current repositories your want to deal with are http repositories that wont work with your ftp client. You might try curl (http://linux.about.com/od/commands/l/blcmdl1_curl.htm) and play around with authentication schemes to find one that matches squeaksource. However just to double-check... I understand your not wanting to use the Save button to store directly to a remote repository because it is hard to undo accidents. However have you specifically discounted the Copy button on the Repository Inspector. Try this proposed workflow... 1. In Monticello Browser, in the left-pane select your package. In the right-pane select the local-package-cache. 2. Unzip the created GiveThisToStef.1.mcz and undertake due-diligence-scan for NDA code. If all okay 3. In Monticello Browser, in the right-pane select your local-package-cache, click the Open button. 4. Select the GiveThisToStef.1.mcz. Click the Copy button. Select the remote repository to upload to. This seems to provide everything with you need to avoid surprises. That way, the code will be where everyone wants it (vs. just attached to email here), and I won't have to worry about what MC might be doing that I didn't anticipate. I know MC can do the whole thing - trouble is it once did something I didn't expect, and I can't have that (legal exposure). I want a clear wall that I deliberately penetrate when I have something to share - it's that simple. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Nick Ager [nick.a...@gmail.com] Sent: Monday, February 06, 2012 2:04 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Alternative to MC for upload? Hi, For private code I began by using an ftp repository then switched to a WebDAV server, With a private WebDAV server you can use Monticello, Gofer etc as though you are using squeak-source - though without a front-end. If you want a front-end there is squeak-source 3 [1] Nick [1] http://ss3.gemstone.com/ss/ss3.html/Overview On 5 February 2012 18:03, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: You're not daft; I'm simply looking for suggestions; yours counts :) From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Göran Krampe [go...@krampe.semailto:go...@krampe.se] Sent: Sunday, February 05, 2012 12:12 PM To: pharo-project@lists.gforge.inria.frmailto:pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Alternative to MC for upload? On 02/05/2012 12:30 PM, Schwab,Wilhelm K wrote: Hello all, I have a fair amount of code that I can't/don't dare release because it involves intellectual property that I do not own, and access under non-disclosure agreements (some of which are silly, but need to be respected regardless). None of that code it is relevant to you (unless you do heart surgery at home), but I need to keep it separate from things like GSL, PLplot, FFI tweaks, etc., that should interest the community. In the past, I've saved to http repositories and been surprised at things (fortunately, nothing toxic) that were released w/o my intent. Squeak Source long since lost the code in question, but it put a fear of MC in me. Is there a way to use gofer or something else to send specific .mcz files that I want to make available? Some other tool? Perhaps I am daft - but why don't you use either local directories for those packages or a private ftp server (like I do)? I use pure-ftpd which is really nice because it can easily map specific users to specific home directories. regards, Göran
Re: [Pharo-project] [update 1.4] #14314
On 2012-02-05, at 12:49, Sven Van Caekenberghe wrote: On 05 Feb 2012, at 11:27, Stéphane Ducasse wrote: 14314 - - Issue 5233:Support Semantic Source Links. Thanks Camillo Bruni. http://code.google.com/p/pharo/issues/detail?id=5233 Now when you press command while clicking on a class name you jump to the class :). Same for the click on a method name and instance variable. Pay attention that this change should really be changed on windows and linux. So please give us feedback. Camillo will do a fix so that menu appears on click down versus click up. Yes ! This is a supercool feature, really. Thx ! One remark though: shouldn't there be any kind of feedback, like underlining the classname/methodname or a popup text ? Sven TODO: - there should be :D (I imagine it exactly like in eclipse, cmd-key pressed = underline all links and display a hand cursor onOver) - telling morphic to do highlighting is a different story |-( - right now you only get onDrag events in – although named onMove – I guess I will have to hack a bit :) - right-click menus should start working again (they're currently slightly broken) - we should have refactoring menus in there (rename instVar/args, push instvar...) cami
Re: [Pharo-project] Alternative to MC for upload?
That looks like a winner. I'll try a test when I'm really awake. Sorry to be dense, but I'm trying to help w/o doing anything awful in the process. Thanks! Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Nick Ager [nick.a...@gmail.com] Sent: Monday, February 06, 2012 3:38 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Alternative to MC for upload? curl -T GiveThisToStef.mcz http://www.squeaksource.com/PharoInbox On 6 February 2012 08:35, Nick Ager nick.a...@gmail.commailto:nick.a...@gmail.com wrote: http://lmgtfy.com/?q=webdav+command-line http://stackoverflow.com/questions/1205101/command-line-utility-for-webdav-upload On 6 February 2012 07:59, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: In honor of Stef, let's make this *really* simple. The pieces for what I want to do MUST exist; I just don't see how to make it happen. So let's say I have GiveThisToStef.mcz on my drive, and I have checked, and rechecked that it is clean and releasable. Can I use an FTP client or some other command line tool to put that in the in box? That way, the code will be where everyone wants it (vs. just attached to email here), and I won't have to worry about what MC might be doing that I didn't anticipate. I know MC can do the whole thing - trouble is it once did something I didn't expect, and I can't have that (legal exposure). I want a clear wall that I deliberately penetrate when I have something to share - it's that simple. Bill From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Nick Ager [nick.a...@gmail.commailto:nick.a...@gmail.com] Sent: Monday, February 06, 2012 2:04 AM To: Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Alternative to MC for upload? Hi, For private code I began by using an ftp repository then switched to a WebDAV server, With a private WebDAV server you can use Monticello, Gofer etc as though you are using squeak-source - though without a front-end. If you want a front-end there is squeak-source 3 [1] Nick [1] http://ss3.gemstone.com/ss/ss3.html/Overview On 5 February 2012 18:03, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: You're not daft; I'm simply looking for suggestions; yours counts :) From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Göran Krampe [go...@krampe.semailto:go...@krampe.se] Sent: Sunday, February 05, 2012 12:12 PM To: pharo-project@lists.gforge.inria.frmailto:pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Alternative to MC for upload? On 02/05/2012 12:30 PM, Schwab,Wilhelm K wrote: Hello all, I have a fair amount of code that I can't/don't dare release because it involves intellectual property that I do not own, and access under non-disclosure agreements (some of which are silly, but need to be respected regardless). None of that code it is relevant to you (unless you do heart surgery at home), but I need to keep it separate from things like GSL, PLplot, FFI tweaks, etc., that should interest the community. In the past, I've saved to http repositories and been surprised at things (fortunately, nothing toxic) that were released w/o my intent. Squeak Source long since lost the code in question, but it put a fear of MC in me. Is there a way to use gofer or something else to send specific .mcz files that I want to make available? Some other tool? Perhaps I am daft - but why don't you use either local directories for those packages or a private ftp server (like I do)? I use pure-ftpd which is really nice because it can easily map specific users to specific home directories. regards, Göran
Re: [Pharo-project] [update 1.4] #14314
On Mon, Feb 6, 2012 at 9:49 AM, Camillo Bruni camillo.br...@inria.frwrote: On 2012-02-05, at 12:49, Sven Van Caekenberghe wrote: On 05 Feb 2012, at 11:27, Stéphane Ducasse wrote: 14314 - - Issue 5233:Support Semantic Source Links. Thanks Camillo Bruni. http://code.google.com/p/pharo/issues/detail?id=5233 Now when you press command while clicking on a class name you jump to the class :). Same for the click on a method name and instance variable. Pay attention that this change should really be changed on windows and linux. So please give us feedback. Camillo will do a fix so that menu appears on click down versus click up. Yes ! This is a supercool feature, really. Thx ! One remark though: shouldn't there be any kind of feedback, like underlining the classname/methodname or a popup text ? Sven TODO: - there should be :D (I imagine it exactly like in eclipse, cmd-key pressed = underline all links and display a hand cursor onOver) that would be awesome :) - telling morphic to do highlighting is a different story |-( - right now you only get onDrag events in – although named onMove – I guess I will have to hack a bit :) - right-click menus should start working again (they're currently slightly broken) - we should have refactoring menus in there (rename instVar/args, push instvar...) cami -- Mariano http://marianopeck.wordpress.com
[Pharo-project] Report from FOSDEM please! :)
...I want to hear how darn cool it was and how droves of new Smalltalkers got reborn :) regards, Göran
Re: [Pharo-project] [update 1.4] #14314
- there should be :D (I imagine it exactly like in eclipse, cmd-key pressed = underline all links and display a hand cursor onOver) - telling morphic to do highlighting is a different story |-( - right now you only get onDrag events in – although named onMove – I guess I will have to hack a bit :) - right-click menus should start working again (they're currently slightly broken) - we should have refactoring menus in there (rename instVar/args, push instvar...) Most of these things have been done in Helvetia. The next most useful thing after code navigation was on-the-fly Code Critics with the yellow wiggly underlines and Ctrl+1 instant-fix. Lukas -- Lukas Renggli www.lukas-renggli.ch
[Pharo-project] ConfigurationOfSIXX status?
Does anyone know the status of the SIXX configuration. I can't get it to load. In general, what does it mean when Gofer doesn't? I hate to repeat myself, but silent failures are one of the worst things a computer can do, and I'm getting them (often). Bill
Re: [Pharo-project] About linkedlist
On 5 February 2012 10:30, Stéphane Ducasse stephane.duca...@inria.fr wrote:
Thanks for the explanation frank
btw (did you dd it in the class comment because it would be gorgeous).
I learned something today so I'm happy.
Now what is the typical use case for such persistent structure?
Indeed I made sure to write a decent class comment :)
The use case is twofold:
* any time you want to stop caring about whether you need to copy a
collection or can safely pass it around (so avoiding the foo copy
addAll: bar; yourself idiom)
* any time you want to be able to undo changes to some structure.
In particular, I wanted to add an or unifier to my unification
library. (Unification is like bidirectional pattern matching. In
particular, we build up an equivalence relation over the nodes in two
structures. After that, if any partitions in the relation contain
variables, we can construct a mapping from variables to concrete
values, to give a most general unifier.) This would let me say can X
or Y unify against this thing? -
(Node left: (Leaf value: #x asVariable)) or: (Node right: (Leaf value:
#x asVariable)) =? someRandomTree
will
* only do something useful if someRandomTree has exactly one child Leaf, and
* will tell us what the value of that Leaf is, by telling us how to
map from the variable called #x to that value.
What I quickly found was that the unification algorithm - which used a
normal, non-persistent (ephemeral) union-find - kept its state after
attempting to unify the first disjunction clause. That meant that
unifying the clause would sometimes fail. What I actually wanted was
to be able to say
* given some partial term relation U,
* try unify the first clause to get a new term relation U1
* but if unification fails, start back with U and try calculate a new
term relation U2 on the second clause's nodes
Using a _persistent_ union-find lets me thus roll back or undo the
term relation construction and revert to an older version.
frank
Stef
On Feb 4, 2012, at 3:33 PM, Frank Shearar wrote:
On 3 February 2012 20:40, Stéphane Ducasse stephane.duca...@inria.fr wrote:
I wasn't sure what double-ended versus single-ended meant, and found some
answer at the obvious place [1]
which mentions Ada.Containers.Vectors is a dynamic array implementation
which seems consistent with C++ [2].
While looking around I happened to bump into [3] which was too much for me
but may be of interest to anyone playing with data structres. Skimming
this
shows it discussing efficiency of data structures in functional languages
together with lazy variants of imperative language data structures. Would
such apply to Smalltalk or is the object-oriented style of Smalltalk
considered imperative rather than functional?
The standard tool set - OrderedCollection, Array, etc., are not
functional at all - (myArray at: 1 put: 2) mutates myArray, - so I'd
put them firmly on the imperative side of the fence.
There's nothing stopping one from writing functional data structures -
Levente Uzonyi's written some persistent data structures, as have I.
(Persistent means you get new versions of a data structure; if you
hang onto those old versions you can roll back your changes.)
Can you explain a bit more Persistent?
Sure! A persistent data structure is an _apparently_ immutable data
structure: editing the structure returns you a _new_ structure. If you
can modify only the latest version of the structure, it's
_partially_persistent_; if you can edit any version it is
_fully_persistent_. Of course edit here means get a new collection
representing the edit
For example, if you load the PersistentUnionFind package (no external
dependencies) and print out this:
| p p1 p2 p3 |
p := PersistentCollection initially: #(1 2 3).
p1 := p at: 1 put: 4.
p2 := p1 at: 2 put: 5.
p3 := p at: 3 put: 0.
{p. p1. p2. p3.} collect: #asArray
you get, with inline comments added:
#(p: #(1 2 3) p1: #(4 2 3) p2: #(4 5 3) p3: #(1 2 0))
So you can see the different versions of the original array: p1 is p
plus one replacement; p2 is p plus two replacements (or equivalently
p1 plus one replacement).
You still get efficient access to the latest version, and the old
versions describe themselves as a stack of undo operations - I'm like
the latest version, but with these changes.
So if you just print out p1, you'll see:
p1 printString. 'Ref(Diff(1, 4, Ref(Diff(3, 3, Ref(Arr(#(1 2 0)))'
The series of Diffs tell you how to get from the latest version - p3 -
to the version of p1: take p3 ( #(1 2 0) ), at index 3 put a 3, and
at index 1 put a 1.
A Ref is a delegate: it allows your reference to something to stay the
same even though the thing referenced changes.
Internally, as you access the latest version of the Collection the
structure rewrites itself: if it's pointing to a Diff it reroots
itself. (This does have the issue that if you hang onto two versions
of the collection and access each version
Re: [Pharo-project] About linkedlist
Hi Stef, Thanks for the explanation frank btw (did you dd it in the class comment because it would be gorgeous). I learned something today so I'm happy. Now what is the typical use case for such persistent structure? Stef Immutable data structures are used extensively in functional languages in which data structures are *im*mutable by default. One benefit of the approach is when multi-threading you don't need to synchronise changes to such structures or objects containing them. For example all Clojure's data-structures are immutable by default [1]. There's been a lot of interesting work on providing performance guarantees so that creating copies avoids scaling with linear time [2], while still having sensible access and iteration performance. [1] http://clojure.org/data_structures#Data%20Structures-Collections [2] http://clojure.org/functional_programming#Functional%20Programming--Immutable%20Data%20Structures Apologies if I'm stating the obvious Nick
Re: [Pharo-project] pharo vision
Hi Stef, Similarly to Philippe my feedback is based on a Seaside/web centric view of how I use Pharo. I'd echo Philippe's concern about looking carefully at how much effort is required to rework Morphic vs using an existing UI library or WebView. From a web centric view I'd emphasis building a remote browsing interface over significant Morphic work. At FOSDEM this weekend I was impressed with the progress Craig Latta has made on spoon recently [1] [2]. Does his work on remote browsing and micro kernels fit into a future Pharo? As I develop with Pharo and deploy with Gemstone, maintaining some level of compatibility between Smalltalks is important. I note the problem raised with XML compatibility between dialects [3]. So the ability to maintain a compatibility layer such as Grease is important, as is the ability to re-use packages between Pharo and Gemstone. [1] http://thiscontext.wordpress.com/ [2] http://netjam.org/spoon/naiad/ [3] http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg56924.html On 5 February 2012 17:43, Philippe Marschall kus...@gmx.net wrote: On 30.01.2012 09:24, Stéphane Ducasse wrote: OK, so here's my take. I try to not turn this into a wish list. Rich libraries While I obviously agree that rich libraries are valuable I believe it's important to have clear guidelines to what should be part of Pharo and what not. In one extreme I could have everything from SqS be part of Pharo. I don't think this is the idea. You don't want to have the same discussion for every library whether it should be part of Pharo. FFI First I think we need to have a problem statement. We want to be able to use libraries written in C from Pharo. We don't implement them in Pharo because we don't have the resources to develop them or Pharo is unsuited for the task. This sucks because it's no longer turtles all the way down but better than nothing. Since blocking C calls block the entire VM until the call returns we need to have threaded-FFI. Yes, I do think that callbacks should be mentioned here. Currently the situation as I understand it is: - use FFI for call-outs - use Alien for call-backs - use NativeBoost for faster callouts? portable plugins? It would be really nice to have a better, more integrated solution here. If that results in something that's more than a one liner for a C call that's fine with me. 64 bit I think it's important to make a distinction between 64bit images and 64 bit VMs. 64 bit VMs Unless you on a small device current systems are 64bit. While most of them offer some sort of way for running 32bit applications this cannot be the way forward since: - it clearly marks the application as legacy - you can only talk to 32bit libraries (see FFI) - we don't know how long this will still be supported (Apple anybody?) I don't know how much work is required to make Cog run on 64bit. 64bit images While it would be nice to have multi gigabyte images (maybe not) I don't think it's realistic to assume we have the resources to come up with a GC that can handle such images. SOAP SOAP is a massive resource sink [1]. Yes it would be nice to have good support but the cost is prohibitive and better spent on other things. Sockets I don't think the socket layer is holding us back. Sure, it's ugly, sure, it can — and should — be improved, but it's not holding us back. IMO it's missing four things: - better documentation with examples, this is important and relatively easy to do - SSL, this is just an issue for clients since servers are fronted anyway. I know Sven's working on this. - sendfile support. This would allow us to send files efficiently over the network without touching user space. Since we're fronted anyway this is not a big deal. - asynchronous support. This would allow us to have a large amount of open connections for things like WebSockets. May be too much work to get it working on Mac/Linux/Windows. This alone doesn't give us WebSockets, we still need to write quite some infrastructure on top of it so you'll probably want to deprioritize if not drop this. I know I have a narrow Seaside-centric focus here. What would be nice is to have a generic client-server framework (how many times have I written a socket-loop?) but I don't think this should be part of Pharo. Load balancer I don't think this needs to be part of Pharo. Apache already does this. UI frameworks: Have you considered cutting your losses? You have your existing infrastructure that requires more resources than you have and if you could you rewrote it. Then in addition you have new requirements and you want to come up with new paradigms. I feel this alone can consume more your entire resources. Options that I would consider: - status quo, maintenance only, no further development - drop UI entirely, go for something like embedded WebKit - make it somebody else's problem, once you have better FFI generate bindings
[Pharo-project] FOSDEM devroom
Yesterday we had a nice day filled with great presentations. Getting to Brussels the day before proved to be a challenge, as the Dutch railways showed to have lots of trouble with 3 cm of snow and a cold night. Andy showed us a good place to eat and talk near the Central Station. In the end all presenters managed to be on time and the whole day ran smoothly. As the devroom was the second day of FOSDEM, we thought it wise not to start too early. That was a good idea, as the ULB was still very quiet when Norbert showed us how to create REST/json/xml based services. Markus followed with the Pharo Vision. Gradually more people came to the devroom until the jQueryMobile presentation was so filled that we had to refuse people entering the room. The Amber presentation also attracted a lot of people new to smalltalk. The ability to create a fast feedback cycle apparently is a major issue for javascript developers. The progress made since ESUG2011 is impressive. The next subjects (working with many cores, making smalltalk fast, spoon) still attracted over 40 participants. The introduction to smalltalk attracted quite a lot of young developers. Some remarks by participants: - a consistent set of keybindings, allowing switching between windows is essential (a developer who has trouble using a mouse for longer periods); - current developers are no longer used to free floating windows, it doesn't matter if it is better, to attract new people you need to remove barriers to entry (a freepascal maintainer); - I would have expected to have started with the basics (we focused on the things we experienced as difficult and different, using the different inspectors and browsers to navigate a large codebase, debugger driven development) And some reminder for ourselves - Tests for the domain model are not enough to ensure that the whole application works correctly; - Throw away old builds; - Check if there are enough power strips. I very much liked talking to people otherwise only known from the mailing lists and the cross-pollination between the different dialects. I would have liked to have more time for discussions. A lunch break might be a good idea. And finally a remark for next years devroom manager: don't expect to see much from FOSDEM :) Stephan Eggermont
Re: [Pharo-project] Creating a file with FS
- it still returns the FSReference... what you want is the following I guess: (wk / 'foo') writeStreamDo: [ :s| s 'bar' ]. since that will - create also create a new file. - ensure closing the stream Yes I did the same. FSReferencewriteStreamDo: doBlock ifPresent: presentBlock Create a file if not present and execute doBlock (with a stream) as argument, if the file is present execute the presentBlock. ^ self isFile ifTrue: [ presentBlock value ] ifFalse: [ self writeStreamDo: doBlock ] FSReferencewriteStreamIfPresent: presentBlock Return a writestream on the receiver if it does not already exist or execute the presentBlock with no argument ^ self isFile ifTrue: [ presentBlock value ] ifFalse: [ self writeStream ] I do not get why we do not get as argument to the presentBlock the file itself? indeed, a [... cull: self] might make sense here :)
Re: [Pharo-project] pharo vision
On Feb 6, 2012, at 12:56 PM, Nick Ager wrote: Hi Stef, Similarly to Philippe my feedback is based on a Seaside/web centric view of how I use Pharo. I'd echo Philippe's concern about looking carefully at how much effort is required to rework Morphic vs using an existing UI library or WebView. From a web centric view I'd emphasis building a remote browsing interface over significant Morphic work. yes but this is a web centric view :). We will have to get decent uibuilder and reuse of logic At FOSDEM this weekend I was impressed with the progress Craig Latta has made on spoon recently [1] [2]. Does his work on remote browsing and micro kernels fit into a future Pharo? I do not know. What is clear is that we are working micro kernels and bootstrap for pharo and we will restart our effort on it. As I develop with Pharo and deploy with Gemstone, maintaining some level of compatibility between Smalltalks is important. I note the problem raised with XML compatibility between dialects [3]. So the ability to maintain a compatibility layer such as Grease is important, as is the ability to re-use packages between Pharo and Gemstone. Indeed now our goal is to absorb as much as possible grease so that there is no need to load grease for pharo this will proved that our libraries will get better. [1] http://thiscontext.wordpress.com/ [2] http://netjam.org/spoon/naiad/ [3] http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg56924.html On 5 February 2012 17:43, Philippe Marschall kus...@gmx.net wrote: On 30.01.2012 09:24, Stéphane Ducasse wrote: OK, so here's my take. I try to not turn this into a wish list. Rich libraries While I obviously agree that rich libraries are valuable I believe it's important to have clear guidelines to what should be part of Pharo and what not. In one extreme I could have everything from SqS be part of Pharo. I don't think this is the idea. You don't want to have the same discussion for every library whether it should be part of Pharo. FFI First I think we need to have a problem statement. We want to be able to use libraries written in C from Pharo. We don't implement them in Pharo because we don't have the resources to develop them or Pharo is unsuited for the task. This sucks because it's no longer turtles all the way down but better than nothing. Since blocking C calls block the entire VM until the call returns we need to have threaded-FFI. Yes, I do think that callbacks should be mentioned here. Currently the situation as I understand it is: - use FFI for call-outs - use Alien for call-backs - use NativeBoost for faster callouts? portable plugins? It would be really nice to have a better, more integrated solution here. If that results in something that's more than a one liner for a C call that's fine with me. 64 bit I think it's important to make a distinction between 64bit images and 64 bit VMs. 64 bit VMs Unless you on a small device current systems are 64bit. While most of them offer some sort of way for running 32bit applications this cannot be the way forward since: - it clearly marks the application as legacy - you can only talk to 32bit libraries (see FFI) - we don't know how long this will still be supported (Apple anybody?) I don't know how much work is required to make Cog run on 64bit. 64bit images While it would be nice to have multi gigabyte images (maybe not) I don't think it's realistic to assume we have the resources to come up with a GC that can handle such images. SOAP SOAP is a massive resource sink [1]. Yes it would be nice to have good support but the cost is prohibitive and better spent on other things. Sockets I don't think the socket layer is holding us back. Sure, it's ugly, sure, it can — and should — be improved, but it's not holding us back. IMO it's missing four things: - better documentation with examples, this is important and relatively easy to do - SSL, this is just an issue for clients since servers are fronted anyway. I know Sven's working on this. - sendfile support. This would allow us to send files efficiently over the network without touching user space. Since we're fronted anyway this is not a big deal. - asynchronous support. This would allow us to have a large amount of open connections for things like WebSockets. May be too much work to get it working on Mac/Linux/Windows. This alone doesn't give us WebSockets, we still need to write quite some infrastructure on top of it so you'll probably want to deprioritize if not drop this. I know I have a narrow Seaside-centric focus here. What would be nice is to have a generic client-server framework (how many times have I written a socket-loop?) but I don't think this should be part of Pharo. Load balancer I don't think this needs to be part of Pharo. Apache already does this. UI frameworks: Have you
Re: [Pharo-project] Creating a file with FS
On 06 Feb 2012, at 09:25, Camillo Bruni wrote: (wk / 'foo') writeStreamDo: [ :s | s 'bar' ]. Yes, this is nice code!
[Pharo-project] Debugger filtering
In the latest Pharo Release we pushed a new Setting for the Debugger: see Settings / Debugging / Filter out common message sends, when enabled the Debugger behaves a bit nicer in most cases by filtering some non-interesting contexts: - self halt will now open the Debugger in the sender context, not somewhere on Halt / Object - sends to Kernel Classes are not shown (like Dictionary #at:ifAbsent: #do: #collect: ...) - a failing TestCase will open the Debugger in the test method itself So all in all it will save you some clicks and concentrate on the important stack elements For those interested in the details or wanting to extend it see Debugger #shouldDisplayContext: best cami
Re: [Pharo-project] [update 1.4] #14314
On 2012-02-06, at 10:43, Lukas Renggli wrote: - there should be :D (I imagine it exactly like in eclipse, cmd-key pressed = underline all links and display a hand cursor onOver) - telling morphic to do highlighting is a different story |-( - right now you only get onDrag events in – although named onMove – I guess I will have to hack a bit :) - right-click menus should start working again (they're currently slightly broken) - we should have refactoring menus in there (rename instVar/args, push instvar...) Most of these things have been done in Helvetia. The next most useful thing after code navigation was on-the-fly Code Critics with the yellow wiggly underlines and Ctrl+1 instant-fix. indeed that sounds cool :)
[Pharo-project] [update 1.4] #14316
14316 - Issue 5251: Remove MCWorkingCopy from startup list http://code.google.com/p/pharo/issues/detail?id=5251 Issue 5167: Fix weak finalization thrashing - improve interrupt behavior http://code.google.com/p/pharo/issues/detail?id=5167 Issue 5224: move deprecated methods from category convenience-inspecting in ToolRegistry to deprecated14 http://code.google.com/p/pharo/issues/detail?id=5224 -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] Debugger filtering
On 6 February 2012 14:48, Camillo Bruni camillo.br...@inria.fr wrote: In the latest Pharo Release we pushed a new Setting for the Debugger: see Settings / Debugging / Filter out common message sends, when enabled the Debugger behaves a bit nicer in most cases by filtering some non-interesting contexts: - self halt will now open the Debugger in the sender context, not somewhere on Halt / Object - sends to Kernel Classes are not shown (like Dictionary #at:ifAbsent: #do: #collect: ...) - a failing TestCase will open the Debugger in the test method itself So all in all it will save you some clicks and concentrate on the important stack elements For those interested in the details or wanting to extend it see Debugger #shouldDisplayContext: I know what proper implementation of it should be: contextsToShow := stack reject: [:context | context method pragmas anySatisfy: [:pragma | pragma keyword == #skipWhileDebugging ] ] like that, you can tag the methods by yourself, instead of making Debugger too clever to decide: Foobar skipWhileDebugging ..some boring code.. and probably the test can be more complicated, since we don't want all #at: method for colleciton, for instance, we should be able to tag only #at: method in Collection itself , so debugger should take the method and check if it overrides a method, which is tagged as unimportant. :) best cami -- Best regards, Igor Stasenko.
Re: [Pharo-project] Debugger filtering
Camillo Bruni wrote: In the latest Pharo Release we pushed a new Setting for the Debugger: see Settings / Debugging / Filter out common message sends, when enabled the Debugger behaves a bit nicer in most cases by filtering some non-interesting contexts: - self halt will now open the Debugger in the sender context, not somewhere on Halt / Object - sends to Kernel Classes are not shown (like Dictionary #at:ifAbsent: #do: #collect: ...) - a failing TestCase will open the Debugger in the test method itself So all in all it will save you some clicks and concentrate on the important stack elements For those interested in the details or wanting to extend it see Debugger #shouldDisplayContext: best cami That is really great. I have found it hard to adapt to jumping back a forth through the 'aBlock value: (self at: index)' in #do: Does that also include all the system fluff occurring prior to executing... self halt. #(1 2 3 4 5) do: [ :x | Transcript crShow: x ] ...in a Workspace ? cheers, ben
Re: [Pharo-project] Debugger filtering
yes I know what proper implementation of it should be: contextsToShow := stack reject: [:context | context method pragmas anySatisfy: [:pragma | pragma keyword == #skipWhileDebugging ] ] like that, you can tag the methods by yourself, instead of making Debugger too clever to decide: Foobar skipWhileDebugging ..some boring code.. and probably the test can be more complicated, since we don't want all #at: method for colleciton, for instance, we should be able to tag only #at: method in Collection itself , so debugger should take the method and check if it overrides a method, which is tagged as unimportant. :) best cami -- Best regards, Igor Stasenko.
Re: [Pharo-project] Basics...Pluggable..Morphs on change
It has been done like that because sometimes ( and in fact quite often for complex UIs ), the model want to perform some actions before the UI is updated. But I am agree that for some instructions, like selection changes, it could (should ?) be send directly by the morph. Ben On Feb 6, 2012, at 5:49 AM, S Krish wrote: I am checking out on the basics of the PluggableTextMorph and PluggableListMorph .. and its cousins. PluggableListMorph changeModelSelection: anInteger setIndexSelector ifNotNil: [model perform: setIndexSelector with: anInteger]. here it is the responsibility of the model to send #changed: getIndexSelector. why..? why not a simpler generic: changeModelSelection: anInteger setIndexSelector ifNotNil: [model perform: setIndexSelector with: anInteger]. sends the call to all dependents of the model implicitly model perform: #changed: with: getIndexSelector thereof the models anywhere need not bother sending #changed: calls... ! similarly: acceptTextInModel . [^setTextSelector isNil or: [setTextSelector numArgs = 2 ifTrue: [model perform: setTextSelector with: acceptedText with: self] ifFalse: [model perform: setTextSelector with: acceptedText]] ] ensure: [unstyledAcceptText := nil]. model perform: #changed with: getTextSelector We can avoid these in the methods if implemented across all Pluggable??Morphs Workspace class openContents: aString ^ self new open; contents: aString; funny is this itself calls #changed: changed: #contents; yourself Makes common sense to me.. rather than expecting the model to explicity call #changed:..this view / widget knows its model and it implicitly invoking #changed: is cleaner abstraction, unless a use case exists which may break infrastructure/ whole base doing this.. This way all models associated with various Pluggable??Morphs will work perfectly fine on just a setter call without extra line being added everywhere in the application code, apps need to bother about changes to other symbol viz: updating a list selection index causes another widget to refresh its content..
Re: [Pharo-project] Basics...Pluggable..Morphs on change
I must say it was an off color moment to state it this way. Rather I should say, morphs must be intelligent to update: themselves, but models can choose to have the #changed: call when they get to have a need to connect more than one view. So i should rewrite the examples as changeModelSelection: anInteger setIndexSelector ifNotNil: [model perform: setIndexSelector with: anInteger]. update this morph implicitly without needing model #changed: call self update: getIndexSelector Similar for the acceptInTextModel, in an MVP world, view or widget has to be intelligent for it's own updates, not wait only on the model or controller to send updates...even for such obvious update On Feb 6, 2012, at 8:46 PM, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: It has been done like that because sometimes ( and in fact quite often for complex UIs ), the model want to perform some actions before the UI is updated. But I am agree that for some instructions, like selection changes, it could (should ?) be send directly by the morph. Ben On Feb 6, 2012, at 5:49 AM, S Krish wrote: I am checking out on the basics of the PluggableTextMorph and PluggableListMorph .. and its cousins. PluggableListMorph changeModelSelection: anInteger setIndexSelector ifNotNil: [model perform: setIndexSelector with: anInteger]. here it is the responsibility of the model to send #changed: getIndexSelector. why..? why not a simpler generic: changeModelSelection: anInteger setIndexSelector ifNotNil: [model perform: setIndexSelector with: anInteger]. sends the call to all dependents of the model implicitly model perform: #changed: with: getIndexSelector thereof the models anywhere need not bother sending #changed: calls... ! similarly: acceptTextInModel . [^setTextSelector isNil or: [setTextSelector numArgs = 2 ifTrue: [model perform: setTextSelector with: acceptedText with: self] ifFalse: [model perform: setTextSelector with: acceptedText]] ] ensure: [unstyledAcceptText := nil]. model perform: #changed with: getTextSelector We can avoid these in the methods if implemented across all Pluggable??Morphs Workspace class openContents: aString ^ self new open; contents: aString; funny is this itself calls #changed: changed: #contents; yourself Makes common sense to me.. rather than expecting the model to explicity call #changed:..this view / widget knows its model and it implicitly invoking #changed: is cleaner abstraction, unless a use case exists which may break infrastructure/ whole base doing this.. This way all models associated with various Pluggable??Morphs will work perfectly fine on just a setter call without extra line being added everywhere in the application code, apps need to bother about changes to other symbol viz: updating a list selection index causes another widget to refresh its content..
[Pharo-project] [update 1.4] #14317
14317 - Issue 5248: Undeclared refs in 14315 http://code.google.com/p/pharo/issues/detail?id=5248 Issue 5167: Fix weak finalization thrashing - another fix http://code.google.com/p/pharo/issues/detail?id=5167 -- Marcus Denker -- http://marcusdenker.de
[Pharo-project] NBOpenGL error every third execution of example
When I do the following with the latest version of NBOpenGL, I get an error: FrameBuffer status: unk error on the third (4th?) evaluation of GLTTRenderingDemo new openInWorld. This happens whether or not another OpenGL example is open. The pattern repeats: 2-3 evaluations work and then the 3rd or 4th has an error. I have seen this error before but didn't realize how easy it was to replicate. Lawson
[Pharo-project] better BehaviormethodDict
Hi mariano I have the impression that methodDict should be redefined as you propose it because else it does not work well with the cannotInterpret hook. I suggest to redefine methodDict as follow. notice the cool comment!!! If this is ok - open a bug entry. Behavior methodDict The method dictionary of a class can be nil when we want to use the cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends the message cannotInterpret: to the receiver but starting the look up in the superclass. Now the system relies that when the message methodDict is sent to a class a method dictionary is returned. The implementation below makes sure that a method dictionary can be nilled but does not confuse the system. methodDict == nil ifTrue: [^ MethodDictionary new ]. ^ methodDict Stef
[Pharo-project] UDP Listener example?
I'm trying to build a display for some instruments that multicast readings using UDP. I started out using CocoaAsyncSocket on Mac (https://github.com/robbiehanson/CocoaAsyncSocket) and I have to say it has a really wonderful api - would be worth cloning it. However, want to do the same thing in Pharo so I have typed this little snippet into the workspace: [| socket | socket := Socket newUDP. 10 timesRepeat: [| s | s := String new. socket receiveDataInto: s fromHost: (NetNameResolver addressFromString:'255.255.255.255' ) port: 4848. Transcript show: s.]] fork and it doesn't seem to do anything. What have I missed? Pharo 1.3 stable on SnowLeopard BTW. Thanks, -Todd Blanchard
Re: [Pharo-project] better BehaviormethodDict
On Mon, Feb 6, 2012 at 10:17 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi mariano I have the impression that methodDict should be redefined as you propose it because else it does not work well with the cannotInterpret hook. I suggest to redefine methodDict as follow. notice the cool comment!!! If this is ok - open a bug entry. Behavior methodDict The method dictionary of a class can be nil when we want to use the cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends the message cannotInterpret: to the receiver but starting the look up in the superclass. Now the system relies that when the message methodDict is sent to a class a method dictionary is returned. The implementation below makes sure that a method dictionary can be nilled but does not confuse the system. methodDict == nil ifTrue: [^ MethodDictionary new ]. ^ methodDict For me that's perfect and avoids an override in my code :) Maybe we can do: Behavior methodDict The method dictionary of a class can be nil when we want to use the cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends the message cannotInterpret: to the receiver but starting the look up in the superclass. Now the system relies that when the message methodDict is sent to a class a method dictionary is returned. The implementation below makes sure that a method dictionary can be nilled but does not confuse the system. methodDict == nil ifTrue: [^ self manageMDFault ]. ^ methodDict Behavior manageMDFault ^ MethodDictionary new That way subclasses can change it without needing an override. but both solutions are fine with me. Other opinions? -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] Snapshot question
On Sun, Feb 5, 2012 at 6:49 PM, Schwab,Wilhelm K bsch...@anest.ufl.eduwrote: I am getting some stalled installations, and hope to be able to snapshot my building image after each successful step (not going so well). With the 1.3 one-click, I can't break (control or alt . ???) something that's gone bad - is there a secret to getting that back? you are missing the '-', aren't you? it is cmd/ctrl . - Re snapshotting the image, I tried #saveSession, but that seems to capturing a bit too much; if it was doing something stupid, it re-opens trying (unsuccessfully as before) to do the same thing, and I can't break out Is there a better way to save incremental progress? Bill -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] UDP Listener example?
Hi Todd, The socket chapter in writing progress could help you: https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Sockets/Sockets.pdf?root=pharobooks I do not remember if the receiveData method is blocking. If not, you should wait til data arrives. Cheers, Jannik On Feb 6, 2012, at 22:22 , Eagle Offshore wrote: I'm trying to build a display for some instruments that multicast readings using UDP. I started out using CocoaAsyncSocket on Mac (https://github.com/robbiehanson/CocoaAsyncSocket) and I have to say it has a really wonderful api - would be worth cloning it. However, want to do the same thing in Pharo so I have typed this little snippet into the workspace: [| socket | socket := Socket newUDP. 10 timesRepeat: [| s | s := String new. socket receiveDataInto: s fromHost: (NetNameResolver addressFromString:'255.255.255.255' ) port: 4848. Transcript show: s.]] fork and it doesn't seem to do anything. What have I missed? Pharo 1.3 stable on SnowLeopard BTW. Thanks, -Todd Blanchard --- Jannik Laval
Re: [Pharo-project] UDP Listener example?
Todd, On 06 Feb 2012, at 22:22, Eagle Offshore wrote: [| socket | socket := Socket newUDP. 10 timesRepeat: [| s | s := String new. socket receiveDataInto: s fromHost: (NetNameResolver addressFromString:'255.255.255.255' ) port: 4848. Transcript show: s.]] fork and it doesn't seem to do anything. What have I missed? It is a non-blocking API, so you have to write some code to keep on listening until some timeout, in a loop with small delays, like 50ms. Also, you have to preallocate a non-empty buffer. I have some working code for this, but it is not clean/standalone enough to show here ;-) If you can't figure it out yourself, just ask and I will mail some of it to you off list. Regards, Sven
Re: [Pharo-project] UDP Listener example?
Thanks, I found this but it pretty well ignores UDP other than mentioning it exists. On Feb 6, 2012, at 1:38 PM, jannik.laval wrote: Hi Todd, The socket chapter in writing progress could help you: https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Sockets/Sockets.pdf?root=pharobooks I do not remember if the receiveData method is blocking. If not, you should wait til data arrives. Cheers, Jannik On Feb 6, 2012, at 22:22 , Eagle Offshore wrote: I'm trying to build a display for some instruments that multicast readings using UDP. I started out using CocoaAsyncSocket on Mac (https://github.com/robbiehanson/CocoaAsyncSocket) and I have to say it has a really wonderful api - would be worth cloning it. However, want to do the same thing in Pharo so I have typed this little snippet into the workspace: [| socket | socket := Socket newUDP. 10 timesRepeat: [| s | s := String new. socket receiveDataInto: s fromHost: (NetNameResolver addressFromString:'255.255.255.255' ) port: 4848. Transcript show: s.]] fork and it doesn't seem to do anything. What have I missed? Pharo 1.3 stable on SnowLeopard BTW. Thanks, -Todd Blanchard --- Jannik Laval
Re: [Pharo-project] UDP Listener example?
Am 06.02.2012 um 23:13 schrieb Eagle Offshore: Thanks, I found this but it pretty well ignores UDP other than mentioning it exists. I think you might confuse the host and port portions of it. If you use socket receiveDataInto:fromHost:port: then the host and the port are the ones of the sending side. You need to specify your own side as well | localPort sourceAddress sourcePort buffer receivedBytes socket delay | localPort := 5000. sourceAddress := NetNameResolver addressFromString: '255.255.255.255'. sourcePort := 4848. buffer := ByteArray new: 1000. delay := Delay forMilliseconds: 50. socket := Socket newUDP setPort: localPort. [[ receivedBytes := socket receiveDataInto: buffer fromHost: sourceAddress port: sourcePort. receivedBytes isZero ] whileTrue: [ delay wait ]] ensure: [ socket closeAndDestroy]. Or you are better off testing it by using #receiveDataInto: instead of #receiveDataInto:fromHost:port: Norbert On Feb 6, 2012, at 1:38 PM, jannik.laval wrote: Hi Todd, The socket chapter in writing progress could help you: https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Sockets/Sockets.pdf?root=pharobooks I do not remember if the receiveData method is blocking. If not, you should wait til data arrives. Cheers, Jannik On Feb 6, 2012, at 22:22 , Eagle Offshore wrote: I'm trying to build a display for some instruments that multicast readings using UDP. I started out using CocoaAsyncSocket on Mac (https://github.com/robbiehanson/CocoaAsyncSocket) and I have to say it has a really wonderful api - would be worth cloning it. However, want to do the same thing in Pharo so I have typed this little snippet into the workspace: [| socket | socket := Socket newUDP. 10 timesRepeat: [| s | s := String new. socket receiveDataInto: s fromHost: (NetNameResolver addressFromString:'255.255.255.255' ) port: 4848. Transcript show: s.]] fork and it doesn't seem to do anything. What have I missed? Pharo 1.3 stable on SnowLeopard BTW. Thanks, -Todd Blanchard --- Jannik Laval
Re: [Pharo-project] better BehaviormethodDict
How many senders of #methodDict would miss-behave? No risk to throw away a freshly basicAddedSelector:withMethod: ? Or should the IDE be aware of the cannotInterpret: experiments ? Maybe the comment should be (seriously): When methodDict instance variable of a class is nil, the VM will redirect any message send to an instance by sending the message cannotInterpret: to the receiver but starting the look up in the superclass. NDLR: Or is it to the next superclass having a non nil methodDict? Since most senders of #methodDict message are unaware of this feature, we try to fool them by providing a new empty MethodDictionary in this case, which shall hopefully make them apparently work. Whether undesirable side effect might occur or not, silently or not, is unspecified. Cross your fingers... Nicolas 2012/2/6 Mariano Martinez Peck marianop...@gmail.com: On Mon, Feb 6, 2012 at 10:17 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi mariano I have the impression that methodDict should be redefined as you propose it because else it does not work well with the cannotInterpret hook. I suggest to redefine methodDict as follow. notice the cool comment!!! If this is ok - open a bug entry. Behavior methodDict The method dictionary of a class can be nil when we want to use the cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends the message cannotInterpret: to the receiver but starting the look up in the superclass. Now the system relies that when the message methodDict is sent to a class a method dictionary is returned. The implementation below makes sure that a method dictionary can be nilled but does not confuse the system. methodDict == nil ifTrue: [^ MethodDictionary new ]. ^ methodDict For me that's perfect and avoids an override in my code :) Maybe we can do: Behavior methodDict The method dictionary of a class can be nil when we want to use the cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends the message cannotInterpret: to the receiver but starting the look up in the superclass. Now the system relies that when the message methodDict is sent to a class a method dictionary is returned. The implementation below makes sure that a method dictionary can be nilled but does not confuse the system. methodDict == nil ifTrue: [^ self manageMDFault ]. ^ methodDict Behavior manageMDFault ^ MethodDictionary new That way subclasses can change it without needing an override. but both solutions are fine with me. Other opinions? -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] NBOpenGL error every third execution of example
could be related to freeing resources/switching to right context. try doing Smalltalk garbageCollect 2 times, after closing the window, before opening it again. On 6 February 2012 22:50, Lawson English lengli...@cox.net wrote: When I do the following with the latest version of NBOpenGL, I get an error: FrameBuffer status: unk error on the third (4th?) evaluation of GLTTRenderingDemo new openInWorld. This happens whether or not another OpenGL example is open. The pattern repeats: 2-3 evaluations work and then the 3rd or 4th has an error. I have seen this error before but didn't realize how easy it was to replicate. Lawson -- Best regards, Igor Stasenko.
Re: [Pharo-project] NBOpenGL error every third execution of example
That takes care of it, even for the case when several windows are open at once: GLTTRenderingDemo new openInWorld. Smalltalk garbageCollect. Smalltalk garbageCollect. GLTTRenderingDemo new openInWorld. Smalltalk garbageCollect. Smalltalk garbageCollect. GLTTRenderingDemo new openInWorld. Smalltalk garbageCollect. Smalltalk garbageCollect. GLTTRenderingDemo new openInWorld. Smalltalk garbageCollect. Smalltalk garbageCollect. L On 2/6/12 6:35 PM, Igor Stasenko wrote: could be related to freeing resources/switching to right context. try doing Smalltalk garbageCollect 2 times, after closing the window, before opening it again. On 6 February 2012 22:50, Lawson Englishlengli...@cox.net wrote: When I do the following with the latest version of NBOpenGL, I get an error: FrameBuffer status: unk error on the third (4th?) evaluation of GLTTRenderingDemo new openInWorld. This happens whether or not another OpenGL example is open. The pattern repeats: 2-3 evaluations work and then the 3rd or 4th has an error. I have seen this error before but didn't realize how easy it was to replicate. Lawson
Re: [Pharo-project] NBOpenGL error every third execution of example
Actually, being able to create and control multiple GL windows was unexpected side effect of my design. My primary goal was to make it work for at least one context. For making things work with multiple contexts, more work to be done by adding things/checks like glMakeCurrent() all over the places, where context switching is likely. On 7 February 2012 05:10, Lawson English lengli...@cox.net wrote: That takes care of it, even for the case when several windows are open at once: GLTTRenderingDemo new openInWorld. Smalltalk garbageCollect. Smalltalk garbageCollect. GLTTRenderingDemo new openInWorld. Smalltalk garbageCollect. Smalltalk garbageCollect. GLTTRenderingDemo new openInWorld. Smalltalk garbageCollect. Smalltalk garbageCollect. GLTTRenderingDemo new openInWorld. Smalltalk garbageCollect. Smalltalk garbageCollect. L On 2/6/12 6:35 PM, Igor Stasenko wrote: could be related to freeing resources/switching to right context. try doing Smalltalk garbageCollect 2 times, after closing the window, before opening it again. On 6 February 2012 22:50, Lawson Englishlengli...@cox.net wrote: When I do the following with the latest version of NBOpenGL, I get an error: FrameBuffer status: unk error on the third (4th?) evaluation of GLTTRenderingDemo new openInWorld. This happens whether or not another OpenGL example is open. The pattern repeats: 2-3 evaluations work and then the 3rd or 4th has an error. I have seen this error before but didn't realize how easy it was to replicate. Lawson -- Best regards, Igor Stasenko.
