I'm a 'Squeak Newbie' for more than a year now, and i really love the language and environment. Now with full closures, traits, Seaside, Magritte, Exupery... (Tweak?, pragmas?) the language is truly limitless and still clean-and-simple (I'm one of the people who really like the Smalltalk syntax ^_^ ).
What's really bugging me is the lack of possibility to use Squeak for 'everyday tasks', like linux scripting, small apps and so on... i don't say it's "impossible", but totally discouraged, unsupported and "forsaken" by most employers.
As it stands now, Squeak *is* a language for long-time Squeakers, OOP learning and language-hacker, maybe mid-sized web apps, but *nothing more*.
I'm forced to learn Ruby (and probably Python) to be able to do my work now, and i do really hate the utterly ugly and evil perl-like syntax, lack of dev environment (Browser? Shout? ...impossible) and the complexity (perplexity?) of this languages.
I've read enough of the discussions and articles regarding Squeaks/Smalltalks future, and this is a sum of the main issues with some personal remarks:
-> *GUI DESIGN* of Squeak is kind-of weird/childish: we don't really need look like window$, but the UI is the first thing man gets to see, so adding a bit of sanity would be nice (anyone using the Skylark theme? @ http://www.comtalk.net/Squeak/87 ...imo this should replace the default one, but porting in 3.9 involves kind of black magic; an alternative theme mimicking the 'redmont' look wold be /though ugly/ nice too ^^; )
-> *no native apps* - kind-of part of GUI, but shouldn't be too hard to get right: we have wxSqueak, maybe we will get Ffenestri... make the first-time users see them ^_^ -->complex graphical apps use the host system only to get a plain window and draw their content by themself (Winamp, most of Miranda, almost all games...) - we should be able to mimick this behavior: make the native windows 'wrap around' SystemWindows and other morphs/Tweak costumes and let BitBlt do it's work. -->i don't really see a reason for the main window being controlled by the VM: it should be possible to show/hide it on-demand and so everybody could choose: Squeak UI like it's now, or loose apps in native windows and let the main window act like the 'java console', but not-even-comparable better. -> *threading* - good to use soft-threads, bad to not-be-able to use host threads, most in the times of multi-core CPUs -->I've read an *really* interesting blog concerning the use of realtime delays (another pain-in-ass) >> http://www.cdegroot.com/blog/2006/02/02/delay-after-delay/, and it really shouldn't be hard to implement Transactional Memory (http://www.cambridge.intel-research.net/~rennals/faststm.html) without breaking image format (breaking delay-using code is no argument, even between minor versions of Squeak, half of the packages get regularly unusable) --->if we had transactional memory *and* externalized VM state, we could fork the interpret for every transaction... or use a predictive scheduler to assign the transactions to a fixed number of host threads ... or there are sure other ways (only guessing, I'm not very proficient in this field).
-> *foreign languages* are another long-time problem: english is good enough for the dev environment, but not for end-user apps, and until the whole image works in Unicode (utf-8), using any language with non-standard charset involves very deep hacking of the image and fonts, much of the free distributed TTF files have complete-enough utf-8 charset, but loading them, the national characters are still unusable (not talking about input conversions).
-> *packages/namespaces* - I've tried VW, and it's packaging system is evil, taking away the simplicity and so the usability; Monticello is good, but not good enough, and without namespaces (http://swiki.krampe.se/gohu/32 is really enough), the image gets very bloated in no time... waiting for M2, waiting for namespace support in newCompiler (could hack it into by myself, but for a compiler generated by SmaCC, it'd be a more-than-dirty solution).
-> *host integration* - no callbacks, insufficient FFI (limited parameters) - it's true anyone can write an own wrapper plugin, but it's very discouraging and complicating the work (a language should aid the developer, not adding tasks).
I thing there is a way Squeak can stay a small, simple and fast environment for embedded dev on one hand and a robust dev language/environment/framework/engine/call-it-as-you-like for system scripting, web/desktop apps, and with Exupery maybe system apps and games too ^__^ (just dreaming..?)
Of course i could do a lot of these 'tasks' myself, and/or aid in others, but by now, there is really no motivation to do it without the community support - it's a lot of changes, depending on each other and sometimes breaking compatibility, and i really don't want to end up with my own branch of VM and image, unsupported and so unusable in the real world out there...
Is there a real possibility to do this kind of 'step in the dark', and evolve Squeak for the use in real word, in our everyday jobs... without losing the community?
Viktor Svub
Interesting mail. I would like see the answers of experts.
2006/5/12, Viktor Svub gilrandir@centrum.cz:
I'm a 'Squeak Newbie' for more than a year now, and i really love the language and environment. Now with full closures, traits, Seaside, Magritte, Exupery... (Tweak?, pragmas?) the language is truly limitless and still clean-and-simple (I'm one of the people who really like the Smalltalk syntax ^_^ ).
What's really bugging me is the lack of possibility to use Squeak for 'everyday tasks', like linux scripting, small apps and so on... i don't say it's "impossible", but totally discouraged, unsupported and "forsaken" by most employers.
As it stands now, Squeak *is* a language for long-time Squeakers, OOP learning and language-hacker, maybe mid-sized web apps, but *nothing more*.
I'm forced to learn Ruby (and probably Python) to be able to do my work now, and i do really hate the utterly ugly and evil perl-like syntax, lack of dev environment (Browser? Shout? ...impossible) and the complexity (perplexity?) of this languages.
I've read enough of the discussions and articles regarding Squeaks/Smalltalks future, and this is a sum of the main issues with some personal remarks:
-> *GUI DESIGN* of Squeak is kind-of weird/childish: we don't really need look like window$, but the UI is the first thing man gets to see, so adding a bit of sanity would be nice (anyone using the Skylark theme? @ http://www.comtalk.net/Squeak/87 ...imo this should replace the default one, but porting in 3.9 involves kind of black magic; an alternative theme mimicking the 'redmont' look wold be /though ugly/ nice too ^^; )
-> *no native apps* - kind-of part of GUI, but shouldn't be too hard to get right: we have wxSqueak, maybe we will get Ffenestri... make the first-time users see them ^_^ -->complex graphical apps use the host system only to get a plain window and draw their content by themself (Winamp, most of Miranda, almost all games...) - we should be able to mimick this behavior: make the native windows 'wrap around' SystemWindows and other morphs/Tweak costumes and let BitBlt do it's work. -->i don't really see a reason for the main window being controlled by the VM: it should be possible to show/hide it on-demand and so everybody could choose: Squeak UI like it's now, or loose apps in native windows and let the main window act like the 'java console', but not-even-comparable better. -> *threading* - good to use soft-threads, bad to not-be-able to use host threads, most in the times of multi-core CPUs -->I've read an *really* interesting blog concerning the use of realtime delays (another pain-in-ass) >> http://www.cdegroot.com/blog/2006/02/02/delay-after-delay/, and it really shouldn't be hard to implement Transactional Memory (http://www.cambridge.intel-research.net/~rennals/faststm.html) without breaking image format (breaking delay-using code is no argument, even between minor versions of Squeak, half of the packages get regularly unusable) --->if we had transactional memory *and* externalized VM state, we could fork the interpret for every transaction... or use a predictive scheduler to assign the transactions to a fixed number of host threads ... or there are sure other ways (only guessing, I'm not very proficient in this field).
-> *foreign languages* are another long-time problem: english is good enough for the dev environment, but not for end-user apps, and until the whole image works in Unicode (utf-8), using any language with non-standard charset involves very deep hacking of the image and fonts, much of the free distributed TTF files have complete-enough utf-8 charset, but loading them, the national characters are still unusable (not talking about input conversions).
-> *packages/namespaces* - I've tried VW, and it's packaging system is evil, taking away the simplicity and so the usability; Monticello is good, but not good enough, and without namespaces (http://swiki.krampe.se/gohu/32 is really enough), the image gets very bloated in no time... waiting for M2, waiting for namespace support in newCompiler (could hack it into by myself, but for a compiler generated by SmaCC, it'd be a more-than-dirty solution).
-> *host integration* - no callbacks, insufficient FFI (limited parameters) - it's true anyone can write an own wrapper plugin, but it's very discouraging and complicating the work (a language should aid the developer, not adding tasks).
I thing there is a way Squeak can stay a small, simple and fast environment for embedded dev on one hand and a robust dev language/environment/framework/engine/call-it-as-you-like for system scripting, web/desktop apps, and with Exupery maybe system apps and games too ^__^ (just dreaming..?)
Of course i could do a lot of these 'tasks' myself, and/or aid in others, but by now, there is really no motivation to do it without the community support - it's a lot of changes, depending on each other and sometimes breaking compatibility, and i really don't want to end up with my own branch of VM and image, unsupported and so unusable in the real world out there...
Is there a real possibility to do this kind of 'step in the dark', and evolve Squeak for the use in real word, in our everyday jobs... without losing the community?
Viktor Svub
Viktor Svub puso en su mail :
-> *host integration* - no callbacks, insufficient FFI (limited parameters) - it's true anyone can write an own wrapper plugin, but it's very discouraging and complicating the work (a language should aid the developer, not adding tasks).
Viktor :
All your post is very clear.
To this point, in Mac you could do a lot via AppleScript and Services.
John do a great job in VM construction for support this,
I do not know if you have Mac, but just in case how about a mini MacSqueak task force for doing examples, etc ?
Could you have time / interest in this ?
Edgar
_________________________________________________________ Hor�scopos, Salud y belleza, Chistes, Consejos de amor: el contenido m�s divertido para tu celular est� en Yahoo! M�vil. Obtenelo en http://movil.yahoo.com.ar
Lic. Edgar J. De Cleene napsal(a):
Viktor Svub puso en su mail :
-> *host integration* - no callbacks, insufficient FFI (limited parameters) - it's true anyone can write an own wrapper plugin, but it's very discouraging and complicating the work (a language should aid the developer, not adding tasks).
Viktor :
All your post is very clear.
To this point, in Mac you could do a lot via AppleScript and Services.
John do a great job in VM construction for support this,
I do not know if you have Mac, but just in case how about a mini MacSqueak task force for doing examples, etc ?
Could you have time / interest in this ?
Edgar
_________________________________________________________ Horóscopos, Salud y belleza, Chistes, Consejos de amor: el contenido más divertido para tu celular está en Yahoo! Móvil. Obtenelo en http://movil.yahoo.com.ar
interest and time: yes, but mac: no chance... i know enough of mac's possibilities with smalltalk and squeak, but i'm win32 & linux user and i'd be happy to see something similar for these mainstream platforms, that's where i really could help, but 'help' is not 'begin' (i don't even know where to start) ^_^ Viktor
I'm a 'Squeak Newbie' for more than a year now, and i really love the language and environment. Now with full closures, traits, Seaside, Magritte, Exupery... (Tweak?, pragmas?) the language is truly limitless and still clean-and-simple (I'm one of the people who really like the Smalltalk syntax ^_^ ).
:)
What's really bugging me is the lack of possibility to use Squeak for 'everyday tasks', like linux scripting, small apps and so on... i don't say it's "impossible", but totally discouraged, unsupported and "forsaken" by most employers.
We started to work on a scripting syntax but we stop. This would be easy to get one.
As it stands now, Squeak *is* a language for long-time Squeakers, OOP learning and language-hacker, maybe mid-sized web apps, but *nothing more*.
I'm forced to learn Ruby (and probably Python) to be able to do my work now, and i do really hate the utterly ugly and evil perl-like syntax, lack of dev environment (Browser? Shout? ...impossible) and the complexity (perplexity?) of this languages.
The fact that companies want to use Ruby or python is not really related to the language but the trends around it. If I would have couple of Million dollars to spend I would have some ideas.
Pay attention Smalltalk is not equal to Squeak. Look at Dolphin Smalltalk: it is really cool!
-> *GUI DESIGN* of Squeak is kind-of weird/childish: we don't really need look like window$, but the UI is the first thing man gets to see, so adding a bit of sanity would be nice (anyone using the Skylark theme? @ http://www.comtalk.net/Squeak/87 ...imo this should replace the default one, but porting in 3.9 involves kind of black magic; an alternative theme mimicking the 'redmont' look wold be /though ugly/ nice too ^^; )
Yes. We started to change the web site. Andrew Tween is working on true type fonts support and we should certainly pay someone to design a look for squeak.
-> *no native apps* - kind-of part of GUI, but shouldn't be too hard to get right: we have wxSqueak, maybe we will get Ffenestri... make the first-time users see them ^_^
Exact!
-->complex graphical apps use the host system only to get a plain window and draw their content by themself (Winamp, most of Miranda, almost all games...) - we should be able to mimick this behavior: make the native windows 'wrap around' SystemWindows and other morphs/Tweak costumes and let BitBlt do it's work. -->i don't really see a reason for the main window being controlled by the VM: it should be possible to show/hide it on- demand and so everybody could choose: Squeak UI like it's now, or loose apps in native windows and let the main window act like the 'java console', but not-even-comparable better. -> *threading* - good to use soft-threads, bad to not-be-able to use host threads, most in the times of multi-core CPUs
-->I've read an *really* interesting blog concerning the use of realtime delays (another pain-in-ass) >> http://www.cdegroot.com/ blog/2006/02/02/delay-after-delay/, and it really shouldn't be hard to implement Transactional Memory (http://www.cambridge.intel- research.net/~rennals/faststm.html) without breaking image format (breaking delay-using code is no argument, even between minor versions of Squeak, half of the packages get regularly unusable) --->if we had transactional memory *and* externalized VM state, we could fork the interpret for every transaction... or use a predictive scheduler to assign the transactions to a fixed number of host threads ... or there are sure other ways (only guessing, I'm not very proficient in this field).
-> *foreign languages* are another long-time problem: english is good enough for the dev environment, but not for end-user apps, and until the whole image works in Unicode (utf-8), using any language with non-standard charset involves very deep hacking of the image and fonts, much of the free distributed TTF files have complete- enough utf-8 charset, but loading them, the national characters are still unusable (not talking about input conversions).
-> *packages/namespaces* - I've tried VW, and it's packaging system is evil, taking away the simplicity and so the usability; Monticello is good, but not good enough, and without namespaces (http://swiki.krampe.se/gohu/32 is really enough), the image gets very bloated in no time... waiting for M2, waiting for namespace support in newCompiler (could hack it into by myself, but for a compiler generated by SmaCC, it'd be a more-than-dirty solution).
Namespaces are not the solution. Manpower is! If you want the new compiler, contact marcus and help improving it.
-> *host integration* - no callbacks, insufficient FFI (limited parameters) - it's true anyone can write an own wrapper plugin, but it's very discouraging and complicating the work (a language should aid the developer, not adding tasks).
I thing there is a way Squeak can stay a small, simple and fast environment for embedded dev on one hand and a robust dev language/ environment/framework/engine/call-it-as-you-like for system scripting, web/desktop apps, and with Exupery maybe system apps and games too ^__^ (just dreaming..?)
No I think that this is possible but just help! Everybody can help.
Of course i could do a lot of these 'tasks' myself, and/or aid in others, but by now, there is really no motivation to do it without the community support - it's a lot of changes, depending on each other and sometimes breaking compatibility, and i really don't want to end up with my own branch of VM and image, unsupported and so unusable in the real world out there...
Just start with some simples changes, get confidence and trust. Help in harvesting for example, writing tests, helping people, trying other codes. I think that stepwise we can slowly get there.
Is there a real possibility to do this kind of 'step in the dark', and evolve Squeak for the use in real word, in our everyday jobs... without losing the community?
I really hope but we need to have more people working for squeak and not simply using it (which is already perfect)
Stef
Viktor Svub
But Dolphin doesn't run in Unix Like and not is opensource.
I'm the most newbie in squeak. I have only been able to dedicate to (this was traduced by google sorry) squeak a few hours, but i hate the logo and the default child interface (sorry), but i'm accustoming
On 12 mai 06, at 17:52, Lord ZealoN wrote:
But Dolphin doesn't run in Unix Like and not is opensource.
I'm the most newbie in squeak. I have only been able to dedicate to (this was traduced by google sorry) squeak a few hours, but i hate the logo and the default child interface (sorry), but i'm accustoming
seriously, me too... and we are working on it. I prefer the squeakfoundation logo :)
--
::Mi blog:: http://blog.lordzealon.com
Well.....i prefer the squeakfoundation logo too :D
2006/5/12, stéphane ducasse ducasse@iam.unibe.ch:
On 12 mai 06, at 17:52, Lord ZealoN wrote:
But Dolphin doesn't run in Unix Like and not is opensource.
I'm the most newbie in squeak. I have only been able to dedicate to (this was traduced by google sorry) squeak a few hours, but i hate the logo and the default child interface (sorry), but i'm accustoming
seriously, me too... and we are working on it. I prefer the squeakfoundation logo :)
--
::Mi blog:: http://blog.lordzealon.com
stéphane ducasse wrote:
...
Is there a real possibility to do this kind of 'step in the dark', and evolve Squeak for the use in real word, in our everyday jobs... without losing the community?
I really hope but we need to have more people working for squeak and not simply using it (which is already perfect)
Stef
Viktor Svub
OK. How experienced does one need to be, and where/how should one volunteer?
OK. How experienced does one need to be, and where/how should one volunteer?
Everybody can carry a little peeble or a stone that is adequate. You can start by writing tests for example. Providing feedback and bugs, bug fixes.... Or working on bigger aspects. I think that the most important aspects is to have a vision and work on it. For example, I would like to see a better support for packages (and I should have a look at MC2 :)).
Stef
On 12-May-06, at 9:39 AM, Charles D Hixson wrote:
stéphane ducasse wrote:
...
Is there a real possibility to do this kind of 'step in the dark', and evolve Squeak for the use in real word, in our everyday jobs... without losing the community?
I really hope but we need to have more people working for squeak and not simply using it (which is already perfect)
Stef
Viktor Svub
OK. How experienced does one need to be, and where/how should one volunteer?
I wrote a message quite a while ago about how even the newest of new newcomers could join in and help.
Basically *anyone* that has a computer capable of running Squeak and a little time and web access can do something helpful. We use Mantis to record bugs/problems/feature requests, so one route would be to look through the lists (http://bugs.impara.de/main_page.php) and look at anything that might pique your interest.
Read the problem description and any notes and see if they make sense; can you actually understand what the problem is supposed to be? Can you replicate the problem at all? If not, email the original reporter to ask if they can help work it out and improve the description, or establish that it got fixed in a more recent release. A non-problem can be closed, removing clutter. A better problem description will help a more experienced user fix it - and you get to learn as you help.
If the problem happens to be something you already understand but can't see a solution, try to write some test to demonstrate it - just a code snippet helps - and some cases that explain what ought to happen if it were fixed. Some bugs are things that people like me could fix quickly if only we knew what the correct response was.
If you do know a solution but can't work out how to program it, explain the solution. If you think you know who might be able to implement your solution ask if they can help you. If you don't know who, ask on the list.
I'd bet that pretty much anyone on this list could progress from total know-nothing-yet beginner to getting-the-idea apprentice with a reputation for being a good contributor in a short time by doing nothing more than the above for a couple of reports a week.
It's our system. It only gets better if we put some work into it.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Quality assurance: A way to ensure you never deliver shoddy goods accidentally.
YEEEESSSSSSSSSSSSSSS
Basically *anyone* that has a computer capable of running Squeak and a little time and web access can do something helpful. We use Mantis to record bugs/problems/feature requests, so one route would be to look through the lists (http://bugs.impara.de/main_page.php) and look at anything that might pique your interest.
Read the problem description and any notes and see if they make sense; can you actually understand what the problem is supposed to be? Can you replicate the problem at all? If not, email the original reporter to ask if they can help work it out and improve the description, or establish that it got fixed in a more recent release. A non-problem can be closed, removing clutter. A better problem description will help a more experienced user fix it - and you get to learn as you help.
If the problem happens to be something you already understand but can't see a solution, try to write some test to demonstrate it - just a code snippet helps - and some cases that explain what ought to happen if it were fixed. Some bugs are things that people like me could fix quickly if only we knew what the correct response was.
If you do know a solution but can't work out how to program it, explain the solution. If you think you know who might be able to implement your solution ask if they can help you. If you don't know who, ask on the list.
I'd bet that pretty much anyone on this list could progress from total know-nothing-yet beginner to getting-the-idea apprentice with a reputation for being a good contributor in a short time by doing nothing more than the above for a couple of reports a week.
It's our system. It only gets better if we put some work into it.
YYYYYYEEEEEESSSSSS
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Quality assurance: A way to ensure you never deliver shoddy goods accidentally.
Hi, a very nice and motivating mail.
I would like to see something like this on the web site (and FAQ), maybe instead of http://squeak.org/Community/ Bug Tracking, something like: How can I help?
A direct link to the current development image and latest vm in the download area, would also be nice.
Greetings, Waldemar Dick
(just looked through mantis).
tim Rowledge schrieb:
On 12-May-06, at 9:39 AM, Charles D Hixson wrote:
stéphane ducasse wrote:
...
Is there a real possibility to do this kind of 'step in the dark', and evolve Squeak for the use in real word, in our everyday jobs... without losing the community?
I really hope but we need to have more people working for squeak and not simply using it (which is already perfect)
Stef
Viktor Svub
OK. How experienced does one need to be, and where/how should one volunteer?
I wrote a message quite a while ago about how even the newest of new newcomers could join in and help.
Basically *anyone* that has a computer capable of running Squeak and a little time and web access can do something helpful. We use Mantis to record bugs/problems/feature requests, so one route would be to look through the lists (http://bugs.impara.de/main_page.php) and look at anything that might pique your interest.
Read the problem description and any notes and see if they make sense; can you actually understand what the problem is supposed to be? Can you replicate the problem at all? If not, email the original reporter to ask if they can help work it out and improve the description, or establish that it got fixed in a more recent release. A non-problem can be closed, removing clutter. A better problem description will help a more experienced user fix it - and you get to learn as you help.
If the problem happens to be something you already understand but can't see a solution, try to write some test to demonstrate it - just a code snippet helps - and some cases that explain what ought to happen if it were fixed. Some bugs are things that people like me could fix quickly if only we knew what the correct response was.
If you do know a solution but can't work out how to program it, explain the solution. If you think you know who might be able to implement your solution ask if they can help you. If you don't know who, ask on the list.
I'd bet that pretty much anyone on this list could progress from total know-nothing-yet beginner to getting-the-idea apprentice with a reputation for being a good contributor in a short time by doing nothing more than the above for a couple of reports a week.
It's our system. It only gets better if we put some work into it.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Quality assurance: A way to ensure you never deliver shoddy goods accidentally.
I would say one of the best places to volunteer, in addition to this list, is on the #squeak chat channel (http://freenode.net/using_the_network.shtml). There you can get real-time mentoring and co-learning, which helps a lot. Also it can take some dialogue just to find a productive way to help that matches someone's interests.
stéphane ducasse napsal(a):
I'm a 'Squeak Newbie' for more than a year now, and i really love the language and environment. Now with full closures, traits, Seaside, Magritte, Exupery... (Tweak?, pragmas?) the language is truly limitless and still clean-and-simple (I'm one of the people who really like the Smalltalk syntax ^_^ ).
:)
What's really bugging me is the lack of possibility to use Squeak for 'everyday tasks', like linux scripting, small apps and so on... i don't say it's "impossible", but totally discouraged, unsupported and "forsaken" by most employers.
We started to work on a scripting syntax but we stop. This would be easy to get one.
That's good news, but how? ^_-
As it stands now, Squeak *is* a language for long-time Squeakers, OOP learning and language-hacker, maybe mid-sized web apps, but *nothing more*.
I'm forced to learn Ruby (and probably Python) to be able to do my work now, and i do really hate the utterly ugly and evil perl-like syntax, lack of dev environment (Browser? Shout? ...impossible) and the complexity (perplexity?) of this languages.
The fact that companies want to use Ruby or python is not really related to the language but the trends around it. If I would have couple of Million dollars to spend I would have some ideas.
Not completely true - some smaller, not-enough-informed companies and even universiti laboratories thing kind of "Smalltalk? that's no real programming language..." I thing there's not enough examles & tutorials for newcomers solving trivial everyday tasks - we concentrate too much on things that can't be done (or are very difficult to do) in other languages... losing the forest for the trees.
Pay attention Smalltalk is not equal to Squeak. Look at Dolphin Smalltalk: it is really cool!
It may be cool, but it's not completely open, you can't modify the VM (afaik) ...and if anybody says 'Smalltalk', i understand 'Squeak' (or VW, worstcase).
-> *GUI DESIGN* of Squeak is kind-of weird/childish: we don't really need look like window$, but the UI is the first thing man gets to see, so adding a bit of sanity would be nice (anyone using the Skylark theme? @ http://www.comtalk.net/Squeak/87 ...imo this should replace the default one, but porting in 3.9 involves kind of black magic; an alternative theme mimicking the 'redmont' look wold be /though ugly/ nice too ^^; )
Yes. We started to change the web site. Andrew Tween is working on true type fonts support and we should certainly pay someone to design a look for squeak.
The web site is *really nice* now ^_^. I know of the fonts. And i don't think there's no one who could make a good design as a bachelor or diplom work (have you seen Skylark, without the rounded corners? it looks nice, clean, simple and professional enough for me).
-> *no native apps* - kind-of part of GUI, but shouldn't be too hard to get right: we have wxSqueak, maybe we will get Ffenestri... make the first-time users see them ^_^
Exact!
-->complex graphical apps use the host system only to get a plainwindow and draw their content by themself (Winamp, most of Miranda, almost all games...) - we should be able to mimick this behavior: make the native windows 'wrap around' SystemWindows and other morphs/Tweak costumes and let BitBlt do it's work. -->i don't really see a reason for the main window being controlled by the VM: it should be possible to show/hide it on-demand and so everybody could choose: Squeak UI like it's now, or loose apps in native windows and let the main window act like the 'java console', but not-even-comparable better. -> *threading* - good to use soft-threads, bad to not-be-able to use host threads, most in the times of multi-core CPUs
-->I've read an *really* interesting blog concerning the use ofrealtime delays (another pain-in-ass) >> http://www.cdegroot.com/blog/2006/02/02/delay-after-delay/, and it really shouldn't be hard to implement Transactional Memory (http://www.cambridge.intel-research.net/~rennals/faststm.html) without breaking image format (breaking delay-using code is no argument, even between minor versions of Squeak, half of the packages get regularly unusable) --->if we had transactional memory *and* externalized VM state, we could fork the interpret for every transaction... or use a predictive scheduler to assign the transactions to a fixed number of host threads ... or there are sure other ways (only guessing, I'm not very proficient in this field).
-> *foreign languages* are another long-time problem: english is good enough for the dev environment, but not for end-user apps, and until the whole image works in Unicode (utf-8), using any language with non-standard charset involves very deep hacking of the image and fonts, much of the free distributed TTF files have complete-enough utf-8 charset, but loading them, the national characters are still unusable (not talking about input conversions).
-> *packages/namespaces* - I've tried VW, and it's packaging system is evil, taking away the simplicity and so the usability; Monticello is good, but not good enough, and without namespaces (http://swiki.krampe.se/gohu/32 is really enough), the image gets very bloated in no time... waiting for M2, waiting for namespace support in newCompiler (could hack it into by myself, but for a compiler generated by SmaCC, it'd be a more-than-dirty solution).
Namespaces are not the solution. Manpower is! If you want the new compiler, contact marcus and help improving it.
Maybe a part of the solution... i think a better package dependency system wold help (like Debians dpkg/apt, but better, of course ^_^ ).
-> *host integration* - no callbacks, insufficient FFI (limited parameters) - it's true anyone can write an own wrapper plugin, but it's very discouraging and complicating the work (a language should aid the developer, not adding tasks).
I thing there is a way Squeak can stay a small, simple and fast environment for embedded dev on one hand and a robust dev language/environment/framework/engine/call-it-as-you-like for system scripting, web/desktop apps, and with Exupery maybe system apps and games too ^__^ (just dreaming..?)
No I think that this is possible but just help! Everybody can help.
I'll do my best ^_-
Of course i could do a lot of these 'tasks' myself, and/or aid in others, but by now, there is really no motivation to do it without the community support - it's a lot of changes, depending on each other and sometimes breaking compatibility, and i really don't want to end up with my own branch of VM and image, unsupported and so unusable in the real world out there...
Just start with some simples changes, get confidence and trust. Help in harvesting for example, writing tests, helping people, trying other codes. I think that stepwise we can slowly get there.
Is there a real possibility to do this kind of 'step in the dark', and evolve Squeak for the use in real word, in our everyday jobs... without losing the community?
I really hope but we need to have more people working for squeak and not simply using it (which is already perfect)
'Perfect' is still too far for me... until i can say "well, i'll do this in Smalltalk", i a don't get an anwer like "wth? o_O" ... ^_~
Stef
Viktor Svub
Thank you very much for the answers, i'll at least try to begin 'somewehere' ^__^
Viktor
That's good news, but how? ^_-
Easy try to get a parser parsing that. Note that for [ ] you can reuse the default parser and that import: declare: variables: classvar:
are packages
KernelPackage import: Point.
Package declare: 'ColoredPointPackage'.
Point < ColoredPoint variables: 'x y' ; classvar: 'Foo'
ColoredPoint>>foo: zork [ <category: 'foobar'> <author: 'sd' date: '24/06/2006'>
^ self foo ]
Not completely true - some smaller, not-enough-informed companies and even universiti laboratories thing kind of "Smalltalk? that's no real programming language..."
what can we say.
I thing there's not enough examles & tutorials for newcomers solving trivial everyday tasks - we concentrate too much on things that can't be done (or are very difficult to do) in other languages... losing the forest for the trees.
Ok but you can fix that by writing such kind of tutorial.
The web site is *really nice* now ^_^. I know of the fonts. And i don't think there's no one who could make a good design as a bachelor or diplom work (have you seen Skylark, without the rounded corners? it looks nice, clean, simple and professional enough for me).
I think that we need a skinnable interface. But did you load skylark in 3.9 We will do a developers image and people can help testing packages.
Maybe a part of the solution... i think a better package dependency system wold help (like Debians dpkg/apt, but better, of course ^_^ ).
Yes I was waiting for that since goran told us. Now if you want to start doing one. Give a try and see.
I'll do my best ^_-
Like me :)
'Perfect' is still too far for me... until i can say "well, i'll do this in Smalltalk", i a don't get an anwer like "wth? o_O" ... ^_~
Tell me where I would have to sign to get that...
Now everybody with its own energy and will can contribute.
Stef
Viktor Svub wrote:
-> *host integration* - no callbacks, insufficient FFI (limited parameters) - it's true anyone can write an own wrapper plugin, but it's very discouraging and complicating the work (a language should aid the developer, not adding tasks).
Can you explain what you mean by "limited parameters" for FFI? Limited how?
Cheers, - Andreas
Andreas Raab napsal(a):
Viktor Svub wrote:
-> *host integration* - no callbacks, insufficient FFI (limited parameters) - it's true anyone can write an own wrapper plugin, but it's very discouraging and complicating the work (a language should aid the developer, not adding tasks).
Can you explain what you mean by "limited parameters" for FFI? Limited how?
Cheers,
- Andreas
Isn't the number of parameters of the called function limited to some fixed count? That can really complicate work with WinAPI... Viktor
Viktor Svub wrote:
Isn't the number of parameters of the called function limited to some fixed count?
No. That's a limitation of Squeak not the FFI. The FFI can deal with arbitrary number of arguments but Squeak can't deal with more than 15 right now. If you really need more you can still construct and invoke your FFI call manually; you just can't use the "inline" declaration.
Cheers, - Andreas
Le Vendredi 12 Mai 2006 19:02, Andreas Raab a écrit :
Viktor Svub wrote:
Isn't the number of parameters of the called function limited to some fixed count?
No. That's a limitation of Squeak not the FFI. The FFI can deal with arbitrary number of arguments but Squeak can't deal with more than 15 right now. If you really need more you can still construct and invoke your FFI call manually; you just can't use the "inline" declaration.
Cheers,
- Andreas
I faced the same problem, and was not fully satisfied with workaround proposed by andreas (build a ExternalLibraryFunction, store it in a class var, and invoke it with an array of arguments, see ExternalFunction>>invokeWithArguments:).
I have a working 3.9 image where i did overcome this limitation. I can have Smalltalk methods with arbitrary number of arguments and FFI primitives called with many arguments also.
The trick is to transparently transform the arguments into a single array argument when Squeak bytecode limit is exceeded.
I did not published yet because decompiler and debugger facility do not work well on such methods. Also the installation order is not trivial because Compiler has to be changed.
However, if you're interested, let me know.
Nicolas
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Charles D Hixson -
Lic. Edgar J. De Cleene -
Lord ZealoN -
nicolas cellier -
Simon Michael -
stéphane ducasse -
tim Rowledge -
Viktor Svub -
Waldemar Dick