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

Re: [Pharo-project] Alternative to MC for upload?

by Schwab,Wilhelm K

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-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Nick Ager [nick.ager(a)gmail.com] Sent: Monday, February 06, 2012 3:38 AM To: Pharo-project(a)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.ager(a)gmail.com<mailto:nick.ager@gmail.com>> wrote: http://lmgtfy.com/?q=webdav+command-line http://stackoverflow.com/questions/1205101/command-line-utility-for-webdav-… On 6 February 2012 07:59, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@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-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Nick Ager [nick.ager(a)gmail.com<mailto:nick.ager@gmail.com>] Sent: Monday, February 06, 2012 2:04 AM To: Pharo-project(a)lists.gforge.inria.fr<mailto: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 <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: You're not daft; I'm simply looking for suggestions; yours counts :) ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of GÃ¶ran Krampe [goran(a)krampe.se<mailto:goran@krampe.se>] Sent: Sunday, February 05, 2012 12:12 PM To: pharo-project(a)lists.gforge.inria.fr<mailto: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

Feb. 6, 2012

Re: [Pharo-project] Alternative to MC for upload?

by Schwab,Wilhelm K

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-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Ben Coman [btc(a)openInWorld.com] Sent: Monday, February 06, 2012 3:35 AM To: Pharo-project(a)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-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Nick Ager [nick.ager(a)gmail.com] > Sent: Monday, February 06, 2012 2:04 AM > To: Pharo-project(a)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 <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: > You're not daft; I'm simply looking for suggestions; yours counts :) > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of GÃ¶ran Krampe [goran(a)krampe.se<mailto:goran@krampe.se>] > Sent: Sunday, February 05, 2012 12:12 PM > To: pharo-project(a)lists.gforge.inria.fr<mailto: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 > > > > >

Feb. 6, 2012

Re: [Pharo-project] pharo vision

by Ben Coman

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-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of S Krish [krishnamachari.sudhakar(a)gmail.com] > Sent: Monday, February 06, 2012 12:31 AM > To: Pharo-project(a)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 <kustos(a)gmx.net<mailto:kustos@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 for GTK/QT/â¦ > This is not giving up. This is not fighting battles you cannot win. > > Plug Computer > Really? You have all the other places that need more resources and you want to do even more. > > Now the things that aren't on your list: > > VM: > Better JIT, allocator, collector. No matter how good your VM is it's never good enough and there's always useful stuff you can add like monitoring. > > #identityHash > It would certainly be nice to have more than 12 hash bits, especially form a performance PoV. IIRC there was once talk of getting rid of compact classes. I take an additional hash bit over an immutability bit any time. > > Infrastructure > If your tools and build infrastructure are holding you back fix them. I would be quite happy if a year from now Pharo is exactly the same and the only thing that changed is the infrastructure you use to build Pharo is way better. I know Seaside sucks at this as well. > > Migration Support > Since you're changing quite a lot of things (SystemDictionary/SmalltakImage, file system, streams, â¦) it would be nice to have support to: > - tell the user where he uses deprecated code > - assist the user in migrating to new APIs > this can also help you migrate everything in Pharo to the new APIs. You probably want to build on top of the rewrite engine of RB. Since you don't have static types the migration can probably only done in a semi-automated way presenting the user a list of possible matches and letting him select the appropriate ones. The deprecation support has been discussed previously. This is probably the only thing in this list that could be put into research papers. > > Releases > I know Seaside sucks at this as well so this isn't a flame. To me as an outsider the release process of Pharo is confusing. I find the release process of Eclipse [2] [3] better. The main points are: > - One main release every year > - Two bugfix releases every year > - after the two bugfix releases a new main release is done and the old main release becomes unsupported > The releases are date driven, not feature driven. The dates for the ga, rc and milestone releases as well as feature and API freezes are set years in advance. That has downsides. For example if your feature misses a deadline, you have to wait for more than a year to see it in a release. But it makes everything nicely planable. > > [1] http://www.innoq.com/soa/ws-standards/poster/innoQ%20WS-Standards%20Poster%… > [2] http://wiki.eclipse.org/Simultaneous_Release > [3] http://wiki.eclipse.org/SimRel/Overview > > Cheers > Philippe > > > > >

Feb. 6, 2012

Re: [Pharo-project] Alternative to MC for upload?

by Nick Ager

curl -T GiveThisToStef.mcz http://www.squeaksource.com/PharoInbox On 6 February 2012 08:35, Nick Ager <nick.ager(a)gmail.com> wrote: > http://lmgtfy.com/?q=webdav+command-line > > http://stackoverflow.com/questions/1205101/command-line-utility-for-webdav-… > > > On 6 February 2012 07:59, Schwab,Wilhelm K <bschwab(a)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-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Nick Ager [ >> nick.ager(a)gmail.com] >> *Sent:* Monday, February 06, 2012 2:04 AM >> >> *To:* Pharo-project(a)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 <bschwab(a)anest.ufl.edu> wrote: >> >>> You're not daft; I'm simply looking for suggestions; yours counts :) >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >>> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of GÃ¶ran Krampe [ >>> goran(a)krampe.se] >>> Sent: Sunday, February 05, 2012 12:12 PM >>> To: pharo-project(a)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 >>> >>> >>> >> >

Feb. 6, 2012

Re: [Pharo-project] Alternative to MC for upload?

by Nick Ager

http://lmgtfy.com/?q=webdav+command-line http://stackoverflow.com/questions/1205101/command-line-utility-for-webdav-… On 6 February 2012 07:59, Schwab,Wilhelm K <bschwab(a)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-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Nick Ager [ > nick.ager(a)gmail.com] > *Sent:* Monday, February 06, 2012 2:04 AM > > *To:* Pharo-project(a)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 <bschwab(a)anest.ufl.edu> wrote: > >> You're not daft; I'm simply looking for suggestions; yours counts :) >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of GÃ¶ran Krampe [ >> goran(a)krampe.se] >> Sent: Sunday, February 05, 2012 12:12 PM >> To: pharo-project(a)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 >> >> >> >

Feb. 6, 2012

Re: [Pharo-project] Alternative to MC for upload?

by Ben Coman

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-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Nick Ager [nick.ager(a)gmail.com] > Sent: Monday, February 06, 2012 2:04 AM > To: Pharo-project(a)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 <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: > You're not daft; I'm simply looking for suggestions; yours counts :) > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of GÃ¶ran Krampe [goran(a)krampe.se<mailto:goran@krampe.se>] > Sent: Sunday, February 05, 2012 12:12 PM > To: pharo-project(a)lists.gforge.inria.fr<mailto: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 > > > > >

Feb. 6, 2012

Re: [Pharo-project] Creating a file with FS

by Camillo Bruni

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 > > > FSReference>>writeStreamDo: 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 ] > > FSReference>>writeStreamIfPresent: 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 >

Feb. 6, 2012

Re: [Pharo-project] pharo vision

by Schwab,Wilhelm K

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-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of S Krish [krishnamachari.sudhakar(a)gmail.com] Sent: Monday, February 06, 2012 12:31 AM To: Pharo-project(a)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 <kustos(a)gmx.net<mailto:kustos@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 for GTK/QT/â¦ This is not giving up. This is not fighting battles you cannot win. Plug Computer Really? You have all the other places that need more resources and you want to do even more. Now the things that aren't on your list: VM: Better JIT, allocator, collector. No matter how good your VM is it's never good enough and there's always useful stuff you can add like monitoring. #identityHash It would certainly be nice to have more than 12 hash bits, especially form a performance PoV. IIRC there was once talk of getting rid of compact classes. I take an additional hash bit over an immutability bit any time. Infrastructure If your tools and build infrastructure are holding you back fix them. I would be quite happy if a year from now Pharo is exactly the same and the only thing that changed is the infrastructure you use to build Pharo is way better. I know Seaside sucks at this as well. Migration Support Since you're changing quite a lot of things (SystemDictionary/SmalltakImage, file system, streams, â¦) it would be nice to have support to: - tell the user where he uses deprecated code - assist the user in migrating to new APIs this can also help you migrate everything in Pharo to the new APIs. You probably want to build on top of the rewrite engine of RB. Since you don't have static types the migration can probably only done in a semi-automated way presenting the user a list of possible matches and letting him select the appropriate ones. The deprecation support has been discussed previously. This is probably the only thing in this list that could be put into research papers. Releases I know Seaside sucks at this as well so this isn't a flame. To me as an outsider the release process of Pharo is confusing. I find the release process of Eclipse [2] [3] better. The main points are: - One main release every year - Two bugfix releases every year - after the two bugfix releases a new main release is done and the old main release becomes unsupported The releases are date driven, not feature driven. The dates for the ga, rc and milestone releases as well as feature and API freezes are set years in advance. That has downsides. For example if your feature misses a deadline, you have to wait for more than a year to see it in a release. But it makes everything nicely planable. [1] http://www.innoq.com/soa/ws-standards/poster/innoQ%20WS-Standards%20Poster%… [2] http://wiki.eclipse.org/Simultaneous_Release [3] http://wiki.eclipse.org/SimRel/Overview Cheers Philippe

Feb. 6, 2012

Re: [Pharo-project] Alternative to MC for upload?

by Schwab,Wilhelm K

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-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Nick Ager [nick.ager(a)gmail.com] Sent: Monday, February 06, 2012 2:04 AM To: Pharo-project(a)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 <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: You're not daft; I'm simply looking for suggestions; yours counts :) ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of GÃ¶ran Krampe [goran(a)krampe.se<mailto:goran@krampe.se>] Sent: Sunday, February 05, 2012 12:12 PM To: pharo-project(a)lists.gforge.inria.fr<mailto: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

Feb. 6, 2012

Re: [Pharo-project] Alternative to MC for upload?

by Nick Ager

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 <bschwab(a)anest.ufl.edu> wrote: > You're not daft; I'm simply looking for suggestions; yours counts :) > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of GÃ¶ran Krampe [ > goran(a)krampe.se] > Sent: Sunday, February 05, 2012 12:12 PM > To: pharo-project(a)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 > > >

Feb. 6, 2012