wheat-developer Mailing List for Wheat (Page 2)
Status: Pre-Alpha
Brought to you by:
mark_lentczner
Menu
▾
▴
wheat-developer — Discussions of current development
You can subscribe to this list here.
| 2005 |
Jan
(7) |
Feb
(28) |
Mar
(10) |
Apr
(20) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Kragen S. <ksi...@co...> - 2005-03-16 18:02:23
|
>From http://del.icio.us/url/4ee193dc83ced854f9324b41d9a5897e : Common tags 20 programming 18 web 12 wiki 7 language 7 webdev 6 wheat 5 blog 3 cms 3 xml 2 rest 2 software 2 proglang 2 dev 2 toread 2 web-development 2 languages 2 server People's comments: xorphus: I think I have to go to the bathroom. stud_muffin: terrifying web-integrated language Anks: Seems like an intresting POV to webdev. Will look in later. ldandersen: REST taken to ridiculous new levels? You decide! joshua: terrifying web-integrated language KirinDave: A very clever approach to web programming. I'm not sure it's The Future(tm) of web programming, but many of the ideas are facinating. Like Zope, but more so. darius: like my Hmph project, supports collaborative development of community websites; but not capability-oriented |
|
From: Mark L. <ma...@gl...> - 2005-03-15 23:27:49
|
You might be amused by my latest hallucinatory delusions on the semantics of Wheat expressions in: http://www.wheatfarm.org/wiki/MarkThinksAboutLanguage - Mark |
|
From: Kragen S. <ksi...@co...> - 2005-03-11 03:15:22
|
On Thu, 2005-03-10 at 15:26 -0500, Jim Kingdon wrote: > > trailing ',' will be allowed (for Kragen) > > Makes sense to me (I think this every time I add something to such a > list in a place which doesn't use the trailing comma and have to > remove/add commas). Doesn't fit with There Is One Way To Do It, but I > haven't quite ever had the chutzpah to advocate requiring the trailing > comma. That's only desirable IMHO if there's a newline between the trailing comma and the close-delimiter ")" or "]". |
|
From: Jim K. <ki...@pa...> - 2005-03-10 20:26:37
|
> trailing ',' will be allowed (for Kragen) Makes sense to me (I think this every time I add something to such a list in a place which doesn't use the trailing comma and have to remove/add commas). Doesn't fit with There Is One Way To Do It, but I haven't quite ever had the chutzpah to advocate requiring the trailing comma. |
|
From: Jim K. <ki...@pa...> - 2005-03-10 16:59:00
|
> If you haven't seen it, you might want to read and comment on: > http://www.wheatfarm.org/wiki/TextSyntaxQuestions Done. I suppose perhaps I should have said something long ago, but I just figured "Well, Mark must have an idea of how this is supposed to work". |
|
From: Mark L. <ma...@gl...> - 2005-03-10 15:16:28
|
Folks - If you haven't seen it, you might want to read and comment on: http://www.wheatfarm.org/wiki/TextSyntaxQuestions I've been implementing newline as terminator and it has raised some thorny issues... - Mark |
|
From: Mark L. <ma...@gl...> - 2005-03-08 22:04:34
|
Friends - I'm about to embark on a number of long-anticipated language changes. These will affect the syntax of Wheat code to a large degree. I will try to do these things in as small increments as possible, but be prepared. Warning: Merging may be painful! When I check in code, of course I'll have updated all checked-in Wheat code. I'll also include detailed instructions for what changed in the check-in comments so you can update any outstanding Wheat changes you may have. Here is my rough planned schedule: - new lines as separators - merge object & array construction syntax, for example: [ x: 3, y: 4 ] [ 3, 4 ] [ 3, size: 4 ] ';' will be a synonym for ',' (for now) trailing ',' will be allowed (for Kragen) - static/dynamic syntax unification (big, scary) - new scope syntax - new comment syntax - new long string syntax - new prototype syntax - primitive declarations new primitive execution technique arguments declared in Wheat code will have to match - local declarations (big, tedious) - ... methods and values (for forward declaration) - ... blocks - direct access to items named in module (siblings, aunts, etc...) - in-line objects w/methods - capturing grandself, & locals Mark |
|
From: Jim K. <ki...@pa...> - 2005-02-28 08:08:00
|
> Horribly embarrassing bug in test framework: The last group of tests > was never run! Proof that the test framework needs a meta-test - but > that requires a separate executable and some amount of Makefile wizardry. Sounds like a challenge to me! I've checked in a unit test for runAll (a real unit test, nothing at the level of Makefiles or executables). The C++ style could probably be improved a bit (I'm not sure about some of the details like function versus static method). There's still some work to do in terms of disentangling the registry() from the test::test constructor (symptom is that "airplane" looks like a test of wheat, when it should just be visible to the new unit test). Such work would probably have good side effects - in terms of having a design which can more easily run only some of the unit tests, for example. Conclusion? Slightly uglier than I had hoped, but by no means worse than anything involving makefiles. P.S. I too noticed the > 0 versus >= 0 bug a day or two ago and told myself, "gee, I really should write a unit test for runAll". But I didn't get around to it until your mention of (gasp! choke!) makefiles drove me to it. |
|
From: Jim K. <ki...@pa...> - 2005-02-28 06:38:02
|
> How would folks feel about all source location information being > limited to just line numbers, not byte/character offsets? Well, I kind of like the idea of the byte/character offsets. I certainly have been using the column to track down errors relatively often. I don't remember specifics (e.g. whether it could be addressed with a better-worded error message). The line-oriented thing has always struck me as, well, punched-card-like. Line oriented editors went out of style decades ago, surely compilers can catch up? Even if the programmer is able to figure out where in the line the problem is, it seems like the column number would help save them the effort and free up a bit of their brain for other tasks. I'm generally a fan of this kind of drudgery-elimination. When the programmer has to wade through extra syntax, extra steps, and the like, it never ceases to amaze me how much of a toll that takes in terms of understanding. Anyway, that is mostly just reactions and random thoughts. Don't take this as a careful weighing of what the column numbers cost us versus what they benefit us. |
|
From: Mark L. <ma...@gl...> - 2005-02-25 18:55:23
|
How would folks feel about all source location information being limited to just line numbers, not byte/character offsets? My thinking is this: 1) It turns out to be quite a bit of work to get the lexer, parser and compiler to generate accurate character offsets. 2) Most Wheat constructs are going to be one per line (it's why we want to make semicolons are optional) 3) Even nested things like: a := #foo(x + #size-increment); will be clear since the messages always reference which message (or variable) has the error.[*] What do you think? - Mark [*] Okay, so it won't be clear where the error is with "message not understood: bork" when the expression was: #chef(language: "se").bork.bork.bork; But, c'mon.... |
|
From: Kragen S. <ksi...@co...> - 2005-02-22 23:38:53
|
On Tue, 2005-02-22 at 13:58 -0800, Mark Lentczner wrote: > Argh! After being stymied much of yesterday due to outages at > SourceForge's CVS server, I took some time to look into distributed > source code control systems. > > I've posted what I've found and some thoughts on the Wiki: > http://www.wheatfarm.org/wiki/ProjectRepository Thanks! I'll write some thoughts here. Subversion isn't particularly hard to set up on a machine you're willing to give people shell accounts on --- it works more or less exactly like CVS. Including the inability to check in intermediate versions when you're offline or the main repository is down. Pretty much all of these systems support the concept that another repository is just a branch, although I think some of them support multiple branches in the same repository. For just getting work done, I'd prefer GNU arch or Darcs to most of the others; for acquiring knowledge that will be useful in the future, I suspect any of GNU arch, Darcs, Monotone, or Codeville would be ideal; and I suspect that Codeville will work better than all of the others relatively soon. |
|
From: Mark L. <ma...@gl...> - 2005-02-22 21:58:39
|
Argh! After being stymied much of yesterday due to outages at SourceForge's CVS server, I took some time to look into distributed source code control systems. I've posted what I've found and some thoughts on the Wiki: http://www.wheatfarm.org/wiki/ProjectRepository - Mark |
|
From: Kragen S. <ksi...@co...> - 2005-02-20 01:24:01
|
On Fri, 2005-02-18 at 07:28 -0800, Mark Lentczner wrote: > Can we checking de-tabify's separately from other changes. > [Not doing this] makes reading the changes very difficult. Yes, I try to do this, for exactly that reason. > I assume that no one is accidentally putting tabs anymore and that this > is just clean up of legacy tabs. Correct? As far as I know; I stuck '(indent-tabs-mode nil) in the custom-set-variables section of my .emacs and the problem seems to have gone away. > Perhaps we should just de-tabify the whole lot in one-fell-swoop. I think that's a good idea in general; I haven't tried it myself only because the tools I've tried using haven't been 8-bit clean. |
|
From: Jim K. <ki...@pa...> - 2005-02-18 16:15:33
|
> I assume that no one is accidentally putting tabs anymore and that this > is just clean up of legacy tabs. Correct? As far as I've noticed, yes. > Perhaps we should just de-tabify the whole lot in one-fell-swoop. Done. Well, for the following. I don't feel as much of a need to do it for ptypes, antlr, and expat, and it would probably make dealing with upstream harder in those cases. wheat: *.cpp *.hpp server: *.cpp *.hpp *.cxx util: *.cpp *.hpp *.h P.S. I assume you know about "cvs diff -w" (but of course that isn't in the diffs which get mailed out etc etc). |
|
From: Mark L. <ma...@gl...> - 2005-02-18 15:28:15
|
Can we checking de-tabify's separately from other changes. It makes reading the changes very difficult. I assume that no one is accidentally putting tabs anymore and that this is just clean up of legacy tabs. Correct? Perhaps we should just de-tabify the whole lot in one-fell-swoop. - Mark |
|
From: Jim K. <ki...@pa...> - 2005-02-17 16:57:21
|
> I'm going to work on getting the source mapping information correct so > that parser errors and runtime errors can refer back to the source. > This seems to be a constant source of pain in our work.... Agreed, thanks. (There are other things, like the known problem with the rendering engine eating much of the trace, and the filename not being shown when a .ws file fails to compile during startup, but the source mapping thing is definitely also right up there). > Byte offsets would be into the UTF8 version of the source. Format 1 or > 2 very easy to generate, but I think it will be easier to store format > 1. Will this work for you and your plans for Buffer and the source > viewer? Byte offset from the beginning would be very easy to deal with in buffer, and I think I like it better (at least, as a way to pass this information to buffer/view). Perhaps the cleanest design (eventually) will be to pass a buffer to the compiler and have it set marks for things it finds (I guess that would be cleaner with named marks. I always assumed marks would have names but I didn't do it yet because we didn't need it yet). That might help with the problems we've seen in terms of "what if the source changes between the last compile and when we view it". But I guess there probably will also be places where we pass the byte offset into wheat as a number, and have wheat code pass that offset to a buffer. That's OK too. |
|
From: Mark L. <ma...@gl...> - 2005-02-17 16:30:47
|
Jim - I'm going to work on getting the source mapping information correct so that parser errors and runtime errors can refer back to the source. This seems to be a constant source of pain in our work.... I'm wondering which format to generate & store: 1) Byte offset from beginning 2) Line number (from 1) and byte offset from start of line 3) Line number (from 1) and character offset from start of line Byte offsets would be into the UTF8 version of the source. Format 1 or 2 very easy to generate, but I think it will be easier to store format 1. Will this work for you and your plans for Buffer and the source viewer? - Mark |
|
From: Jim K. <ki...@pa...> - 2005-02-15 17:15:46
|
> I made a file release on SourceForge tonight. Anyone want to try to > pull it and triple check that I didn't screw it up? Works fine for me. |
|
From: Jim K. <ki...@pa...> - 2005-02-15 16:33:28
|
> File release works great for me. Should the animal farm be in the > checked-in /development checkpoint, perhaps? Either that or we should have documentation (for example, on the start.html page) walking people through the process of creating a project for it. |
|
From: Kragen S. <ksi...@co...> - 2005-02-15 16:16:51
|
RmlsZSByZWxlYXNlIHdvcmtzIGdyZWF0IGZvciBtZS4gIFNob3VsZCB0aGUgYW5pbWFsIGZhcm0g YmUgaW4gdGhlIGNoZWNrZWQtaW4gL2RldmVsb3BtZW50IGNoZWNrcG9pbnQsIHBlcmhhcHM/IA0K |
|
From: Mark L. <ma...@gl...> - 2005-02-15 07:11:41
|
Okay - I made a file release on SourceForge tonight. Anyone want to try to pull it and triple check that I didn't screw it up? (I did screw it up once but I fixed it... I think... no, I checked.... really... -- ack, I love/hate sourceforge!) - Mark |
|
From: Mark L. <ma...@gl...> - 2005-02-14 22:14:42
|
Our CodeCon 2005 presentation was well received. Thanks to Jim and Kragen for all their work on the demo. There was at least one mention in the press: And after the very first Sunday presentation, one audience member claimed he found the new web programming language Wheat "so beautiful, it's made me cry!" -- The Register http://www.theregister.co.uk/2005/02/14/codecon_2005 In the flurry of progress in the days leading up to the demo the first rudiments of Farm, the development environment, got written. We have also have definitely turned the corner and are writing more Wheat code than C++! If you are interested in playing with the system, we'll be putting up a tar ball release on SourceForge before the end of the week. If you like it and are interested in contributing, we'd love your help. We'll be planning the next release cycle soon and are hoping for a real alpha release this Summer. - Mark & the Wheat Team |
|
From: Jim K. <ki...@pa...> - 2005-02-14 08:18:13
|
I've just checked in a variety of fixes, most notably to have view render via a template (an ugly one, but a template nonetheless). It is now plenty fast (didn't try a really big file, but there was no noticeable pause on, say, blog.ws or animal.ws). One lesson is that (especially in a hairy case like this) it is valuable to have HTML-level tests. I wrote most of the unit tests against the expander, and was mystified when it didn't work in my browser. After a false start or two, I wrote a unit test to look at the rendered HTML (test-render-view-bad-compile-location), and the cause became clear. What is "is-failure" and "failure-code" in the checked in version was (in the buggy version), a single tt:span where is-failure is now. Trying to reason about this at the expander level might have worked if I had a bit more sleep or something, but it was easier to write the test at the HTML level, because I knew what I wanted to see, but I had no "what does one see in the browser" type insight into what the expander should do. Now, for this bug at least, the HTML test could be end to end, or it could just feed in a dummy expander and check the output. |
|
From: Jim K. <ki...@pa...> - 2005-02-14 04:56:52
|
> here is a small patch which corrects a problem with the Mac OS X > instructions in the readme. Checked in (thanks). I'm sure Mark (our resident XCode user) will let me know if things are more complicated, but your patch matches my memory of how the XCode build works. |
|
From: Donovan P. <wh...@ul...> - 2005-02-13 20:33:33
|
Hello, It appears that the other patch I had (to the xcode file, removing some stale file references) is already in HEAD, but here is a small patch which corrects a problem with the Mac OS X instructions in the readme. Donovan |
