Hello Squeakers!
My job search is turning up dead ends, hurry up and wait, and unfathomably boring prospects. Screw all that! I want to do something cool. I'm thinking about doing a KickStarter, but almost all of my ideas are either a) stuff no one else wants which only I could possibly think would be cool, or b) overly ambitious. The words Andreas used to describe my last idea: "a bit grandiose." Gift for understatement at times. So I'm looking for something which could be completed by one or two geeks in six months to a year, which people actually want, to be implemented (at least in part) using Squeak, and to be released at the end under the MIT license. I've floored my expenses, so I can make my own labor (relatively, for a guy living in Seattle) very cheap. By floored, I mean the room I sleep in isn't even tall enough to stand up in -- I do not presently meet the definition of a free-range chicken -- and I've disconnected my cellular service. I want to be an efficient engine for getting things that matter to me and other people done, rather than go on being some tool used to ship lucrative enterprise crapware. So here's the $x question: what do you want me to do? I have a Raspberry Pi on order, so bonus points if you can work that in somehow. The person with the best (realistic) idea will be credited for it. Inspire me! And thanks for reading all the way down to the bottom of this message. Casey |
Below, with my original message deleted for brevity. On Mar 8, 2013, at 2:20 AM, Angel Java Lopez <[hidden email]> wrote:
I really don't think Squeak is the state of the art, so we don't have to worry about that part. VPRI will probably take care of that for us in the long run. But that's a research system and we have a rock solid system NOW that we can apply to real problems. How lucky and priveledged are we? I'd say: pretty damned lucky. |
I wasn't finished writing but wiping the rain off the phone decided the matter for me accidentally. Yes, a "distributed Smalltalk" is absolutely a very interesting thing to pursue, in part because the idea behind object oriented programming was supposed to be separate async intercommunicating nodes in a network of other self similar things, but... Other other people have taken up this line of inquiry and produced interesting results already. Most recently, David Ungar, who's work I think we all really should be at least familiar with, has even recently explored this. I think this is a great idea for a project, but yet again I'm not sure I can help much, beyond activating and mobilizing supporters for this kind of work. FWIW, I have CC'd David, on the off chance that he wants to keep exploring this category of inquiry, and if there's anything at all that I can do to help with raising funds: either with Smalltalk or with Self, I'll be damned if I don't try to put some wind in these sails. I must admit that I am an adoring fan of Self. Read that as you will:) What do you think, David? Should we crowd-source funding more work on the Roar VM? Or is there something else I should be fighting for?
|
In reply to this post by Casey Ransberger-2
On 2013-03-08, at 07:48, Casey Ransberger <[hidden email]> wrote: > Hello Squeakers! > > My job search is turning up dead ends, hurry up and wait, and unfathomably boring prospects. > > Screw all that! I want to do something cool. > > I'm thinking about doing a KickStarter, but almost all of my ideas are either a) stuff no one else wants which only I could possibly think would be cool, or b) overly ambitious. The words Andreas used to describe my last idea: "a bit grandiose." Gift for understatement at times. > > So I'm looking for something which could be completed by one or two geeks in six months to a year, which people actually want, to be implemented (at least in part) using Squeak, and to be released at the end under the MIT license. > > I've floored my expenses, so I can make my own labor (relatively, for a guy living in Seattle) very cheap. By floored, I mean the room I sleep in isn't even tall enough to stand up in -- I do not presently meet the definition of a free-range chicken -- and I've disconnected my cellular service. I want to be an efficient engine for getting things that matter to me and other people done, rather than go on being some tool used to ship lucrative enterprise crapware. > > So here's the $x question: what do you want me to do? I have a Raspberry Pi on order, so bonus points if you can work that in somehow. > > The person with the best (realistic) idea will be credited for it. > > Inspire me! And thanks for reading all the way down to the bottom of this message. > > Casey Implement a usable touch-interface for Etoys. - Bert - |
In reply to this post by Casey Ransberger-2
On Thu, Mar 7, 2013 at 11:48 PM, Casey Ransberger
<[hidden email]> wrote: > Hello Squeakers! > > So here's the $x question: what do you want me to do? I have a Raspberry Pi on order, so bonus points if you can work that in somehow. > > The person with the best (realistic) idea will be credited for it. > > Casey Hi Casey, Since you asked for ideas, I'll throw a few out there. 1) Get modern graphics facilities up and running in the squeakvm, either rome, athens, or gezira, or something else Pros: Smalltalk, and by extension Squeak have always been oriented towards the graphical. Heck it's where much of what we use everyday comes from! So it's kind of a drag that when I go to draw a path in Squeak my choices are a heavily aliased path in the standard canvas, or a weird set of rectangles joined together on the balloon canvas. Gezira is from VPRI and gets points for compactness. Plus Bert has already done a lot of the work implementing it. Athens is being done in Pharo and uses NativeBoost I believe so there is that hurdle. Rome used Cairo I believe and has some work completed but was somewhat abandoned. Cons: Gezira is largely the product of one man and may fall victim to a low bus factor if this person decides to work on other things. Also I don't know how good its performance is. Athens uses NativeBoost and possibly a bunch of other Pharoisms. That may slow your effort. Rome hasn't seen any work in a while so I don't know what state it is currently in. 2) Work to implement some of the RoarVM concepts into the regular SqueakVM Pros: My computer seems to acquire more cores with each passing year, but 100000 factorial still only maxes out one of them. This is a shame. Allowing squeak to utilize the numerous threads that we all have access to will be vital in ensuring its relevance in the coming years. The RoarVM already allows this in a Squeak image. Combined with Eliot's work on JITing Smalltalk code Squeak could rule the world! Cons: RoarVM was part of a research project and as I understand it the straight-line performance is far behind the regular squeak VM. It also appears to be a fairly substantial fork of the regular VM, so there could probably be a lot of work involved on both the image side and the VM side in getting its facilities integrated. STRETCH GOAL 3) Read the asm.js spec at http://asmjs.org and then go to emscripten.org and read up on the compiler. Then figure out how to compile a minimal VM to javascript that can run in the browser and slowly build your way up from there, implementing more and more plugins and primitives in javascript until a small squeak image can run. Pros: Mozilla spent $150 million last year developing their browser, and likely Google, Microsoft and Apple did the same. The amount of money being poured into making browsers faster, quicker to draw, better at collecting garbage, etc, is pretty insane. There are likely more people working on just the Mozilla garbage collector than people working on Squeak/Pharo fulltime. Asm.js is designed to allow for the compilation of C programs to rigidly defined JS which will be executed by the browser at speeds currently 2-3x slower than the C code. This is still really fast and they expect greater speedups in the future. The emscripten compiler translates draw calls into Canvas calls, sound calls into Audio API calls, etc, etc. Basically most of the primitives needed by Squeak are available as Javascript APIs, so the vm calls to C code could be converted to Javascript calls. Overall this would allow Squeak to utilize the vast resources being poured into browsers and Javascript, while bringing along the far superior language and development environment we all enjoy. Cons: Relying on Canvas draw calls rather than BitBlt, for example, will reduce the whole "from the metal up" feel that you can currently get with Squeak. This is also obviously a very ambitious project that would take a lot of work. It would also chain Squeak to a standard that can change or die out at some point in the future. It would also make it hard to run squeak in a very memory or processor constrained environment. Anyway, you asked for ideas and those are 3 of them. Hopefully that wall of text wasn't too much for you. Best of luck! Jeff |
Hi:
On 08 Mar 2013, at 16:44, Jeff Gonis wrote: > 2) Work to implement some of the RoarVM concepts into the regular SqueakVM > > Pros: My computer seems to acquire more cores with each passing year, > but 100000 factorial still only maxes out one of them. This is a > shame. Allowing squeak to utilize the numerous threads that we all > have access to will be vital in ensuring its relevance in the coming > years. The RoarVM already allows this in a Squeak image. Combined > with Eliot's work on JITing Smalltalk code Squeak could rule the > world! > > Cons: RoarVM was part of a research project and as I understand it the > straight-line performance is far behind the regular squeak VM. It > also appears to be a fairly substantial fork of the regular VM, so > there could probably be a lot of work involved on both the image side > and the VM side in getting its facilities integrated. This is indeed the better approach. I would use the CogVM as a starting point instead of the existing RoarVM. So far, Cog is 'simple' enough, and there are only a few things, for instance the polymorphic inline caches that are problematic. For things like primitives etc, Igor's HydraVM also provides relevant improvements. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 |
Hi all,
On our Smalltalk VM ( Samsung Win8 Notebook I7 ) Time millisecondsToRun: [ 100000 factorialRecursive ] 9567 Time millisecondsToRun: [ 100000 factorial2p ] 10797 Time millisecondsToRun: [ 100000 factorialIterative ] 9548 regards, Frank -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Stefan Marr Gesendet: Freitag, 8. März 2013 17:26 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Re: [Newbies] I need an idea. I know you have some.Give. Hi: On 08 Mar 2013, at 16:44, Jeff Gonis wrote: > 2) Work to implement some of the RoarVM concepts into the regular SqueakVM > > Pros: My computer seems to acquire more cores with each passing year, > but 100000 factorial still only maxes out one of them. This is a > shame. Allowing squeak to utilize the numerous threads that we all > have access to will be vital in ensuring its relevance in the coming > years. The RoarVM already allows this in a Squeak image. Combined > with Eliot's work on JITing Smalltalk code Squeak could rule the > world! > > Cons: RoarVM was part of a research project and as I understand it the > straight-line performance is far behind the regular squeak VM. It > also appears to be a fairly substantial fork of the regular VM, so > there could probably be a lot of work involved on both the image side > and the VM side in getting its facilities integrated. This is indeed the better approach. I would use the CogVM as a starting point instead of the existing RoarVM. So far, Cog is 'simple' enough, and there are only a few things, for instance the polymorphic inline caches that are problematic. For things like primitives etc, Igor's HydraVM also provides relevant improvements. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 |
In reply to this post by Bert Freudenberg
On Fri, Mar 8, 2013 at 7:00 AM, Bert Freudenberg <[hidden email]> wrote:
Oh! Heart-strings! Yes, this needs to be done. I can probably even do it... you know I spent a few weeks racking my brain about what if anything I could do to improve Etoys before I sent out the call for ideas, and I drew a blank. One thought I rejected was rebasing it off of Trunk, which I threw out because I know there's already an effort underway, and the scope of the work is more broad than I'm comfortable with.
When I was playing with Etoys on the iPad, one thing I really felt needed to change was the way the keyboard was shown and hidden. I didn't like anything I came up with. I'm nearly convinced that we need a soft keyboard that's implemented in Smalltalk -- it doesn't feel right that this intrinsic part is not made out of the same stuff as everything else -- but that's not a small task. There's a whole dictionary of autocompletion you need, and it has to be fuzzy, to try to guess what the user tried to type based on the probability that it matches a particular term.
I wonder if I could hijack some of the logic from OCompletion/ECompletion. I might actually narrow the scope to just the keyboard. Either way, this one is definitely in the running. Thanks for the idea, Bert!
Casey Ransberger |
In reply to this post by Jeff Gonis-2
Hi Jeff,
Actually I've gotten a few suggestions offlist along the lines of graphics stuff for Squeak. This is an area I'm actively exploring. Thanks for the suggestions! Also, thanks for putting me onto asm.js. This is cool.
On Fri, Mar 8, 2013 at 7:44 AM, Jeff Gonis <[hidden email]> wrote: On Thu, Mar 7, 2013 at 11:48 PM, Casey Ransberger Casey Ransberger |
Connectors 3D... Ken G. Brown, from my iPhone
|
Free forum by Nabble | Edit this page |