On 25/07/2008, at 9:18 PM, Stefan Schmiedl wrote: > Clearing, perhaps via context menu. I have a better, generic solution than a context menu, that I hope to publish this weekend. > What happens if I start editing? Does the red blob shift around? If you consider the inline marker, then yes. If you consider the below-the-line marker, then the 'spike' would move, and the marker would move (by bigger leaps) if the spike required it to. This would minimize the visual disruption. A variable spike position relative to the marker is necessary to deal flexible with left-end-of-the-view and right-end-of-the-view error positions, so it makes sense to allow it to move. And it would feel quite slick I think. > How do I "delete the content to which [an error marker] applies"? A source marker corresponds to a range in the text. If that range is deleted, then the marker would disappear. Imagine the text that is currently marked in red by the error system as being the range of the marker. > Practically all errors I'm getting in my source code are caused > by unbalanced parentheses or brackets. How do you decide upon the > content when the syntax is invalid? If one were to do the minimum change from the current code, the error marker would be pinned to the character immediately after where the error message is currently inserted. Remember that this is a simple interface change to an existing mechanism, and the existing mechanism consists of an error message + a position. > Somehow I feel like the marketing consultant asking about which color > the wheel should have, before it can be invented. So don't listen to > my > musings. These sort of questions are valuable to flesh out the details. > Have a nice weekend And you. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 If a train station is a place where a train stops, what's a workstation? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by davidbuck
What I like watching is the "defensive crouch" approach, whereby a
clearly dated approach (pasting the error string into the method body) gets defended to the death as "the one true way" by so many people. Don't take that example too personally; there are lots of things like that in the product that people defend against all reason. This does demonstrate how hard it can be for a vendor to make changes in a longstanding product though :) James Robertson Cincom Smalltalk Product Evangelist http://www.cincomsmalltalk.com/blog/blogView Talk Small and Carry a Big Class Library On Jul 25, 2008, at 6:15 AM, David Buck wrote: > Stefan Schmiedl wrote: >> With the "error as comment" approach, you could double click on a >> delimiting quote and easily remove the bugger. Sounds like a small >> job >> for somebody knowing his way around the editor. Objections anybody? >> >> s. >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > I object. If you turn the error into a comment it will compile once > the > actual error is fixed and you don't notice the error message. You'll > start seeing error messages scattered throughout your code in > comments. > > I like the approach of treating errors like breakpoint markers. > Backspace should get rid of them and saving the method gets rid of > them. > > David Buck > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Sounds like our Church -- "if you change that, I am going to
move to the xxxx Church" -- so if you change the darn error message thing, I am going to start using Java!! James Robertson wrote: What I like watching is the "defensive crouch" approach, whereby a clearly dated approach (pasting the error string into the method body) gets defended to the death as "the one true way" by so many people. Don't take that example too personally; there are lots of things like that in the product that people defend against all reason. This does demonstrate how hard it can be for a vendor to make changes in a longstanding product though :) James Robertson Cincom Smalltalk Product Evangelist http://www.cincomsmalltalk.com/blog/blogView Talk Small and Carry a Big Class Library On Jul 25, 2008, at 6:15 AM, David Buck wrote:Stefan Schmiedl wrote:With the "error as comment" approach, you could double click on a delimiting quote and easily remove the bugger. Sounds like a small job for somebody knowing his way around the editor. Objections anybody? s. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwncI object. If you turn the error into a comment it will compile once the actual error is fixed and you don't notice the error message. You'll start seeing error messages scattered throughout your code in comments. I like the approach of treating errors like breakpoint markers. Backspace should get rid of them and saving the method gets rid of them. David Buck _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc -- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@... Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by James Robertson-7
On Fri, 25 Jul 2008 08:23:38 -0400
James Robertson <[hidden email]> wrote: > What I like watching is the "defensive crouch" approach, whereby a > clearly dated approach (pasting the error string into the method body) Clearly dated does not mean "obsolete". It's just a different approach from the "let's pop another dialog" way everybody else is doing. From my keyboard-centric point-of-view, it's much nicer than that stupid dialog telling me that a local variable's name is never used, which has a Cancel button right there, but Esc does not work. Most of the time, I see this thing right after I told VW in the preceding dialog that I want to declare the variable as temporary. Having vented, I'm now going to remove this thing from my image. Shutting up now, s. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Dennis smith-4
Hello,
A friend of mine
wanted to install VWNC and ran into a problem. I cannot duplicate it and don't
know how to help him. Does anybody here have a
suggestion?
Thanks.
Ivan
Here is a manual
transcript of his problem, possibly somewhat inaccurate, especially since I am
translating his notes from another
language.:
Typical Install -
Next
Then:
Nothing detected to install. Click other to
specify an install.map file in the
install
source directory.
After
clicking Other:
Enter the location of the
install.map file
Files of type:
*.map
After
selecting All
types
and
entering VWInstallerWin.exe
I
get
Unhandled exception: Message not
understood
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Is this using the ISO file, or the network installer?
James Robertson Cincom Smalltalk Product Evangelist Talk Small and Carry a Big Class Library On Jul 25, 2008, at 9:25 AM, Ivan Tomek wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
I understand that he is using the
installer.
Ivan
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by James Robertson-7
Unfortunately, this is only made worse when the current
approach requires a change in habits or mindset. New users see it as a bad way, not simply a different way. One clue is if your experienced users find something annoying. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of James Robertson > Sent: Friday, July 25, 2008 8:24 AM > To: VW NC > Subject: Re: [vwnc] Developers from other languages trying Smalltalk > > What I like watching is the "defensive crouch" approach, whereby a > clearly dated approach (pasting the error string into the method body) > gets defended to the death as "the one true way" by so many people. > Don't take that example too personally; there are lots of things like > that in the product that people defend against all reason. > > This does demonstrate how hard it can be for a vendor to make changes > in a longstanding product though :) > > > James Robertson > Cincom Smalltalk Product Evangelist > http://www.cincomsmalltalk.com/blog/blogView > Talk Small and Carry a Big Class Library > > > > > On Jul 25, 2008, at 6:15 AM, David Buck wrote: > > > Stefan Schmiedl wrote: > >> With the "error as comment" approach, you could double click on a > >> delimiting quote and easily remove the bugger. Sounds like a small > >> job > >> for somebody knowing his way around the editor. Objections anybody? > >> > >> s. > >> _______________________________________________ > >> vwnc mailing list > >> [hidden email] > >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > I object. If you turn the error into a comment it will compile once > > the > > actual error is fixed and you don't notice the error message. You'll > > start seeing error messages scattered throughout your code in > > comments. > > > > I like the approach of treating errors like breakpoint markers. > > Backspace should get rid of them and saving the method gets rid of > > them. > > > > David Buck > > > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by James Robertson-7
Am 25.07.2008 um 14:23 schrieb James Robertson: > This does demonstrate how hard it can be for a vendor to make changes > in a longstanding product though :) It may be hard, but it definitely pays. Smalltalk is supposed to make hard things easier and the impossible possible, but from the pov of a developer coming from other languages, it looks more like it makes the hard things easier and the easy things harder. The other day I had to evaluate Adobe InDesign on the Mac. I was surprised this flagship monster product is not a native Aqua application. It does not even integrate well with OSX and doesn't feel as snappy as, say Pages. It looks Adobe went to great lengths to build some cross-platform UI foundation. The point I'm trying to make is: Pro-level products like InDesign, QuarkXPress, FrameMaker and such could easily also be developed in Smalltalk. The main challenge here is a complex domain model and to keep huge and deep data structures stable, extensible and maintainable. Two thinks Smalltalk is extremely good at. It can make these hard things easier. IMO there is significant commercial potential in it. Vendors urgently need to save costs for cross-platform development (in 2004 Adobe abandoned FrameMaker for the Mac due to the high costs for maintaining the three platforms Win/Mac/Solaris). Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Ivan Tomek
Ivan Tomek escreveu:
> Hello, > > A friend of mine wanted to install VWNC and ran into a problem. I cannot > duplicate it and don't know how to help him. Does anybody here have a > suggestion? [snipped] > Here is a manual transcript of his problem, possibly somewhat > inaccurate, especially since I am translating his notes from another > language.: [snipped] > > *Unhandled exception: Message not understood* It would help if we knew which version of VW and in what platform is the attempt being done... -- Cesar Rabak GNU/Linux User 52247. Get counted: http://counter.li.org/ _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Andre Schnoor
Andre Schnoor escreveu:
> Am 25.07.2008 um 03:34 schrieb Cesar Rabak: > >> Smalltalk influenced most of mainstream languages and introduced the >> traits that now make *those* languages/environments/technologies >> compelling so now switch to Smalltalk would have a too little return >> for >> the effort/resources. > > These languages still don't support closures (AFAIK) and don't have > that much power under the hood regarding native compilation and > efficient garbage collection. They might be nice for web scripting, > but not so much for fat clients and desktop applications. > Ah closures! Yhe nice idea Smalltalk got from Lisp, right!? I think closures are homologous to mainstream languages as recursion used to be in early seventies wrt COBOL. . . Closures do not map to higher productivity in the typical business oriented SW development. Smalltalk also failed to become mainstream for fat clients and desktop applications, in fact client side apps made in Smalltalk are seen as 'fatter' than done in other languages. Even as proof of concept we are short than other 'esoteric' languages. Scheme, for example, has its SIAG spreadsheet with a lot of functionality, we don't have a compeling spreadsheet (or word processor, for that matter) even as an example of the use of the language. > However, I must admit the impressive Ruby and Python support that now > comes with XCode 3 out of the box looks like a real threat. Writing > 100% native applications in dynamic languages is already possible. If > Smalltalk doesn't keep up quickly, it will get more difficult to > explain its advantages to newbies. IMNSHO we're already at this stage! -- Cesar Rabak GNU/Linux User 52247. Get counted: http://counter.li.org/ _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steve Aldred-3
Steve Aldred escreveu:
> Terry Raymond wrote: >> Jim >> >> Ok. >> >> As you have said, do you want to run a good enough system >> like Windows or a great one like the Mac. >> > > I don't remember the last time I saw anybody use a vanilla VW > environment which tends to say that isn't good enough. > Humm... this smells like a fallacy. One of the editors mentioned here (Emacs) is also normally heavily customized by their users and no one would map that to 'isn't good enough', wouldn't? > Perhaps a good use of one of James' surveys would be to poll what addons > people use. Take those that appear universal and add them to a > development image for distribution using whatever quality controls you > need - just add them so the "first look" experience is much better. The issue with this thread wrt '"first look"' experience is the strangeness factor when comparing to established customs in other environments. -- Cesar Rabak GNU/Linux User 52247. Get counted: http://counter.li.org/ _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by stéphane ducasse-2
stéphane ducasse escreveu:
> I think that there is a room for the following scenario. > - I code my application or script in the editor I want. > If I prefer to code it into the best integrated IDE I use a smalltalk > image one. > > - I can run my application/scripts on the command line > smallscript/rb myapp > > - when I have a problem I run > smallscript/rb -db myapp > and I get the full environment I can debug with our lovely debugger > For the average Smalltalk environment, or the focus of this list, VW, it will not cut. Scripting with smalltalk is possible (see GNU Smalltalk) for example, but you end having to put much more in the text since you don't have the RB to organize the code, so to ease the task GNU St started to put more syntax (now errors are coming with line numbers). OTOH, the mindset of scripting is different of the one you designing classes and methods: why should I strive to 'encapsulate' or 'hide information' if all is the same script¹? -- Cesar Rabak GNU/Linux User 52247. Get counted: http://counter.li.org/ [1] This was brought to my attention in last year by an intern who looked at startup code for GNU Smalltalk especially the command line parsing code. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Lukas Renggli-2
Excellent, Lucas. Good luck in this.
On Fri, Jul 25, 2008 at 12:55 AM, Lukas Renggli <[hidden email]> wrote: FYI: _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Ivan Tomek
PLEASE DO NOT DO THIS! THIS EMAIL DISCUSSION IS INTERESTING AND IMPORTANT AND SHOULD NOT BE POLLUTED WITH SOME IRRELEVANT NON_SEQUITUR! USE A DIFFERENT SUBJECT PLEASE!
On Fri, Jul 25, 2008 at 6:25 AM, Ivan Tomek <[hidden email]> wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Cesar Rabak
Am 25.07.2008 um 16:55 schrieb Cesar Rabak:
> Ah closures! Yhe nice idea Smalltalk got from Lisp, right!? Sure. But I wouldn't consider Lisp a viable application development language nowadays anymore (no flame war please). > I think closures are homologous to mainstream languages as recursion > used to be in early seventies wrt COBOL. . . > Closures do not map to higher productivity in the typical business > oriented SW development. Then we are talking about different things. I meant the ability to create control structures and frameworks easily by using blocks as arguments. This clearly is a huge productivity advantage. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Eliot Miranda-2
On Jul 25, 2008, at 8:31 AM, Eliot Miranda wrote:
> PLEASE DO NOT DO THIS! THIS EMAIL DISCUSSION IS INTERESTING AND > IMPORTANT AND SHOULD NOT BE POLLUTED WITH SOME IRRELEVANT > NON_SEQUITUR! USE A DIFFERENT SUBJECT PLEASE! Chuckle, I had this thought a *long* time ago. Not that I'm not enjoying the thread immensely. But it's scope ballooned beyond the purported topic a while ago. Good to see activity on the list though. :) -- Travis Griggs Objologist "It's [a spec] _the_ single worst way to write software, because it by definition means that the software was written to match theory, not reality" - Linus Torvalds _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Andre Schnoor
Andre Schnoor escreveu:
> Am 25.07.2008 um 16:55 schrieb Cesar Rabak: > >> Ah closures! Yhe nice idea Smalltalk got from Lisp, right!? > > Sure. But I wouldn't consider Lisp a viable application development > language nowadays anymore (no flame war please). > OK. Lispers obviously differ, but this is not the point... >> I think closures are homologous to mainstream languages as recursion >> used to be in early seventies wrt COBOL. . . >> Closures do not map to higher productivity in the typical business >> oriented SW development. > > Then we are talking about different things. I meant the ability to > create control structures and frameworks easily by using blocks as > arguments. This clearly is a huge productivity advantage. We're talking about the same *thing* what we disagree is the perception it would have in the productivity _at large_. Regards, -- Cesar Rabak GNU/Linux User 52247. Get counted: http://counter.li.org/ _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Colin Putney
Colin Putney a écrit :
> > Compare that to this problem I ran into when starting out in VW. I > apparently have the habit of doing the following sequence of actions > when editing text: > > - select some text > - cut > - select some other text > - delete > - type something > - paste > > Everywhere but VW, that leads to the text I cut being inserted back into > the document. In VW, I get the text that I *deleted.* The text I wanted > to move is gone, and the text I wanted to get rid of is preserved. Argh! > > The habits I've developed from working with computers *since I was a > kid* work against me. It took me weeks to figure out exactly what was > going wrong, and then another week or two until I stumbled across the > NoCutDelete package. Even after I knew that I had to avoid deleting a > selection, I couldn't do it - the habits were too deeply engrained. > > And the VW behavior is just silly - why have two separate editing > operations that are exactly the same? Why is there no way to delete text > without destroying the clipboard? Even if you ignore the conventions > that the rest of the world uses, this is bad design for a text editor. > Isn't there a shift paste proposing last 5 copy/cut anymore? Yes there is. A little bit more keyboard hits though... Nicolas _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Travis Griggs-3
At the risk of bringing this discussion back on topic... I see the following issues being potential impediments to use of VW as perceived by people from other languages/environments. I've tried to steer clear of issues that are generic to all Smalltalks (the unique syntax, etc) and stick to things that are VW-specific:
1. No readily available bindings for common open source libraries. Things like libpng, libjpeg, expat, etc. There are tons of free libraries like this that solve lots of common problems, and VW looks far less powerful than (say) Ruby or even C if these bindings don't exist (or exist in the public repository in various states of brokenness). Even where native VW versions exist, a developer from another language has to learn an entirely new API and has no guarantee that a particular feature will be supported. 2. No easy deployment strategy. Runtime Packager is a decent tool, but it's a lot more intimidating than something integrated, with a "click here to build your .exe or .app" button. 3. Look & feel. I agree with some of the comments here about the look and feel being an initial turn-off. Regardless of what platform you're on, the VW widgets feel like a cheap imitation of native widgets. Most of my apps use custom or one-off widgets because I need to tweak some behavior of the standard ones -- and it's amazing what just a little Cairo gradient can do to spruce things up. I don't need or want native widgets, just nice looking ones that don't have any pretense of being native. 4. Source control. Store is workable, and I see it improving more rapidly now (the new shadow loader is a big step in the right direction), but the whole system seems slow, underpowered, and overly infrastructure-bound compared to some of the cool distributed SCM systems out there. These are not issues that bother me, just ones that I've seen my new employees (and others to whom I've given demos or training) respond to negatively. And I admit a free software bias -- I don't have any experience developing in other commercial environments. -- Ken Treis Miriam Technologies, Inc. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |