wheat-developer Mailing List for Wheat (Page 3)
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-02-13 19:35:42
|
More in the series; I'm removing these from animal.ws:
`` wheatbug: unknown tags and attributes in the tt: namespace (and
`` perhaps also tags and attributes with no declared namespace?)
`` should produce error messages. It took me a long time to figure
`` out why my misspelled tt:name attribute wasn't producing results...
`` wheatbug: [ #foo ] isn't a legal (static) list. (This obviously
`` has to wait for closure stuff to work.
`` wheatbug: $../foo := 3 gives you bad-inst-value; you have to write
`` it ($..).foo := 3.
`` wheatbug: "Save without compiling" is an unusual option.
`` wheatbug: some weird stuff seems to happen if I do foo := self;
`` #foo = foo;
`` wheatbug: "foo".contains(!!!("")) should return the original error,
`` not failed-conversion(as-string).
`` wheatbug: likewise, "" + !!!("").
|
|
From: Kragen S. <ksi...@co...> - 2005-02-11 03:27:16
|
I've been "playing user" as I write this 20-questions demo app. I've
run into a number of minor problems that will present themselves to new
Wheat developers; most of them won't show up during the demo, but
they'll show up when people download the tarball and try to run it.
Many of these are things that we will no longer be able to notice
ourselves in another week or two, which is why I'm writing them down
now; I don't know that we necessarily need to fix them all now, or even
soon, but we should be careful not to forget about them.
My recent checkin points at some more serious problem I don't fully
understand, I think. I hope someone will have a chance to look at it
tonight or tomorrow morning to figure out what's wrong with Wheat (or,
alternatively, what's wrong with my head that I couldn't see what I was
doing wrong.)
Here are the few that will show up during the demo:
`` wheatbug: attractive gray column containing error messages etc. is
`` too narrow for pathnames etc., so they spill out of it on the right
`` in an ugly fashion
`` wheatbug: <a name="error"> is on the line *after* the syntax error,
`` so href="?op=view#error" results in ensuring that the error itself
`` is *not* displayed on the screen -- it's just above the top of the
`` window.
`` wheatbug: view page is too slow for things with more than a few
`` dozen lines of code.
Here are the others that will probably not show up during the demo:
`` wheatbug: if the tests object doesn't inherit run-all
`` (because it's not derived from the right thing) then the
`` compile page crashes when it fails to run the tests.
`` wheatbug: commenting out the last line of code results in a syntax
`` error if it didn't end with a newline, just because newlines in
`` comments are syntax errors. Tokenizing errors actually.
`` wheatbug: failure to tokenize (like the previous problem) leaves
`` the error highlight on the previous successfully-tokenized token.
`` wheatbug: ordinary variable names inside {::} or in -> link
`` expressions don't work.
`` wheatbug: you can save the .ws file behind the back of the compile
`` machinery, and it tries to pick some random place to display
`` whatever previous error existed, until the next time you hit
`` "compile".
`` wheatbug: failing tests don't have a link to show you the source of
`` the failing test.
`` wheatbug: error message on compile page doesn't look like a link,
`` although it is.
`` wheatbug: "unexpected token: foo" should usually say "expected ;"
`` or something of that nature, since usually the unexpected token
`` isn't actually visually close to the error. Perhaps this will go
`` away when semicolons before newlines are optional. This does
`` sometimes work: 'expecting ";", found '}''.
`` wheatbug: quotes in "expecting ";", found '}'" error message are
`` inconsistent.
`` wheatbug: system/method/exception/unknown-local(sample-animal-game)
`` should tell me where the error is in the source file! Presumably
`` this is an error that compile is returning.
`` wheatbug: failure messages from tests are generated as ASCII but
`` then carelessly shoehorned into HTML, so ill-formed stuff inside
`` there will break the template.
`` wheatbug: if you #replace-content with something that's not
`` well-formed XML, the resulting ill-formed-XML message does not
`` contain enough information to make the problem location clear. I
`` think there may also be things, like DTDs, that can occur in
`` well-formed XML, but not in arbitrary places within XML, so the
`` failure condition may be more complex here.
`` wheatbug: isn't there a better way to escape XML than by running it
`` through the expand primitive?
`` wheatbug: x: (\n""(\n""))\n fails to parse (unexpected ")")
`` wheatbug: there should be a shorter way to write this method:
`` expand(template: t, subject: s, expander: e): {
`` return $/library/render.expand(template: \\t, subject: \\s, expander: \\e);
`` }
`` wheatbug: this code should not be a syntax error:
`` return $/library/render.expand(
`` template: \#results-template,
`` expander: #results-expander(results),
`` );
`` wheatbug: the message "While expanding tag passed-class (fetching
`` instruction)" should not refer to passed-class as a "tag", since
`` it's not an XML or HTML tag.
|
|
From: Kragen S. <ksi...@co...> - 2005-02-10 02:02:09
|
On Wed, 2005-02-09 at 09:14 -0800, Kragen Sitaker wrote: > On Tue, 2005-02-08 at 23:32 -0800, Mark Lentczner wrote: > > I have redone the task list with priorities. Kragen: If you are > > looking for something to spend a few hours on tomorrow morning, perhaps > > a first crack at the animal guessing game would be a good thing to do. > > Great, I'll whack at it. Have done some bits --- mostly been a very distracted day. Planning to spend the morning with you, Mark, if you're available, and I'll work more on the project in the morning. |
|
From: Kragen S. <ksi...@co...> - 2005-02-09 17:15:33
|
On Tue, 2005-02-08 at 23:32 -0800, Mark Lentczner wrote: > I have redone the task list with priorities. Kragen: If you are > looking for something to spend a few hours on tomorrow morning, perhaps > a first crack at the animal guessing game would be a good thing to do. Great, I'll whack at it. |
|
From: Mark L. <ma...@gl...> - 2005-02-09 07:32:23
|
I have redone the task list with priorities. Kragen: If you are looking for something to spend a few hours on tomorrow morning, perhaps a first crack at the animal guessing game would be a good thing to do. - Mark |
|
From: Jim K. <ki...@pa...> - 2005-02-09 07:19:26
|
> Can someone explain this section added to farm.ws: Well, column could be measured in: (b) bytes (c) characters, or (w) character width Our current bug relates to (b) vs (c), as you point out. The comment is about a hypothetical bug in terms of (w) (given the situation, implemented by kterm and such programs, of ASCII = width one; Japanese = width two). Maybe the comment should just say "check that the compiler and the viewer agree on what a column is (bytes vs characters vs other choices like character width or whatever)". > When we report messages - we shouldn't be using that value as > "column", but instead need to use it to compute offset in the byte > stream of the source and then either a) compute the character position > or b) use it to format the text differently. The later is preferable. I wonder if we want something along the lines of the buffer/marker abstraction in emacs. |
|
From: Mark L. <ma...@gl...> - 2005-02-08 23:24:45
|
Can someone explain this section added to farm.ws:
``( The japanese characters here are interesting, because they
are traditionally twice as wide as ASCII characters in
non-proportional fonts. So the subtle aspect of this test
is that everyone involved agrees on what a "column" is.
Guess what? Wheat flunks it!!! So it is commented out :-(
``)
source-text-odd-characters:
""(
parses: "x<y || &foo > 5 || ニュース"
error: "<&>" bad "<&>"
next-line: "don't <stop> 日本語"
"")
`` This is the case: "bad" is where the error happens
`` error: "<&>日本語" bad "<&>ニュース"
Is this supposed to be implying that "column", based on a count of
bytes, would be correct from the viewpoint of a column on a fixed-width
font display of the source? Because that isn't so: Japanese characters
in UTF-8 are three bytes long...
As it sits now - the compiler, thanks to the implementation in Antlr,
thinks in terms of bytes. When it says "column 7" it means the 7th
byte into the line. When we report messages - we shouldn't be using
that value as "column", but instead need to use it to compute offset in
the byte stream of the source and then either a) compute the character
position or b) use it to format the text differently. The later is
preferable.
- Mark
|
|
From: Jim K. <ki...@pa...> - 2005-02-08 04:40:26
|
> or simple export DebugBuild=yes in your environment variables. Excellent! This seems like a simple solution to my concerns about how to pick either the debug or non-debug build. |
|
From: Mark L. <ma...@gl...> - 2005-02-08 03:08:20
|
I just checked in the change that causes the Makefile build to build an
optimized build by default.
If you want a debug build either uncomment out the line
export DebugBuild=yes
in the top level Makefile, or simple export DebugBuild=yes in your
environment variables.
The optimized build is really worth it:
Pentium III, 850Mhz, FedoraCore 3, 512M ram
g++ (GCC) 3.4.2, glibc 2.3.4
running bin/wheat-r1 -t root/config-web-test.xml
Debug build
user 0m9.367s
user 0m9.361s
user 0m9.378s
avg 0m9.369s
Optimized build
user 0m5.835s
user 0m5.824s
user 0m5.837s
avg 0m5.832s
62% the time
1.6x faster
- Mark
|
|
From: Mark L. <ma...@gl...> - 2005-02-06 06:44:23
|
I just checked in a bad version of path.cpp - you may want to dial it back to revision 1.4 - Mark |
|
From: Jim K. <ki...@pa...> - 2005-01-24 05:09:07
|
I've just checked in a change which renders test results in the farm (as opposed to text results in a <pre>). The first obvious thing about what I did is that I didn't do it with templates. Really, I tried to be good and use templates. If you look at project.html you can even see where I was putting the tt:names. What made me stop (at least for now) was just how ugly and hard to test the code was getting to generate the context. Generating the context was way more complicated than generating the HTML. OK, administer the lashes, but I'm pretty much unrepentant unless there is a way to write the template-based version, and its tests, more cleanly than what my template-based attempt was starting to look like. The next thing is that the graphic design could use some work. I did pick a red and green that differ in luminosity (please preserve this property, I request on behalf of the 5% of the population without good red-green color vision). Oh, and I changed the summary to omit the number of passes (it still prints the total tests and number of failures). I found the version with 3 numbers cluttered. (I did also check junit, and noted that at least the junit runners I checked don't print the number of passes). |
|
From: Jim K. <ki...@pa...> - 2005-01-24 04:52:11
|
In CVS logs Mark writes: > introduced concept of debug-string() for objects > reverted debug-info() to exactly match low-level debugInfo() > added some is-string() calls where missing (string, number, boolean) > temporarily decided that booleans *shouldn't* respond to is-string/as-string This looks like a good cleanup. As for things like "should booleans respond to is-string/as-string?", if such questions get difficult, it means we are trying to overload too many different features into as-string. In the case of wheatunit, I certainly want to head in the direction of being able to change the issue from "how to render as string" to "how to render as HTML". I've just checked in something which takes a first step in that direction, but there are enough issues in that checkin that I'll send a separate message about it. |
|
From: Mark L. <ma...@gl...> - 2005-01-22 16:37:30
|
On Jan 22, 2005, at 8:14 AM, Jim Kingdon wrote: > Thanks to Fedora Core 3, I can provide the compiler checks :-(. GCC > 3.4 is the default compiler there. Okay - I downloaded FC3 last night and I'll install it today on a server... Alas, my main build machine is still my Mac and it is gcc3.3. But I'll be able to test build easily enough, and this bug will only surface when introducing new classes. - Mark |
|
From: Jim K. <ki...@pa...> - 2005-01-22 16:15:00
|
> Yup, I knew this, but without compiler checks, it is hard to catch by > hand ;-) Thanks to Fedora Core 3, I can provide the compiler checks :-(. GCC 3.4 is the default compiler there. For the moment, I've worked around the problem by installing the compat-gcc-c++ package (which is GCC 3.3). |
|
From: Mark L. <ma...@gl...> - 2005-01-22 07:44:07
|
On Jan 21, 2005, at 10:44 PM, Jim Kingdon wrote: > Wheat does not build with GCC 3.4. Ack! > This is due not to a bug but a feature of GCC 3.4: the copy > constructor must be visible... Yup, I knew this, but without compiler checks, it is hard to catch by hand ;-) > (1) CHECK_SAME and HERE. A copy constructor on pt::testlocation would be trivial and safe. One does have to be careful that a testlocation object doesn't out-live any this->from testlocation. Since they are generally allocated on the stack in the correct order, this isn't an issue, but exposing the copy constructor and assignment operator makes it look to users that they can treat them as storable values, which they are not. None-the-less, exposing the copy constructor is fine. > I've enclosed a patch which would fix I'm more inclined to fix it at the testlocation class. > (2) Assignable. Again, I think the right way to fix this is to add the copy constructors. Reference (inherits from Assignable) already has one, and all the sub-classes of Reference (Local, Self, Argument, etc...) don't add any data members. Hence, they could all have a copy constructor trivially. The sub-classes of Assignable in value.hpp would be only be slightly harder. Most have a few (or zero) simple data members, and the copy constructor is trivial. Object and Array would just need some careful eyeballs to ensure that all the private data gets copied over correctly. > Given that Linux distributions are starting to ship with GCC 3.4 as > the default compiler, it seems like we should do something about this. > But what? Okay, Okay, I'm downloading RedHat FC3 now... Then I assume I can get gcc3.4 for it. Is this the distro where you ran into this? - Mark |
|
From: Jim K. <ki...@pa...> - 2005-01-22 06:44:33
|
Wheat does not build with GCC 3.4. This is due not to a bug but a feature of GCC 3.4: the copy constructor must be visible (even if the compiler is allowed to skip calling it) when passing an rvalue foo to something expecting a foo&. http://gcc.gnu.org/bugs.html#cxx_rvalbind I believe this affects us in two places: (1) CHECK_SAME and HERE. I've enclosed a patch which would fix CHECK_SAME, but HERE would still have issues in places like checkvar in server/utils.cxx. I'm assuming that making the copy constructor of pt::testlocation public would be OK here, although I'm sure I'm less familiar with the implications than a real C++ programmer. (2) Assignable. Code such as Local postArgs(f); postArgs = Object(); is affected. And this is fairly common (especially in places like value-test.cpp, baselibrary.cpp, baselibrary-test.cpp, etc). Maybe a few dozen cases in our code base (slightly fewer than I expected, but not a tiny number). Fixing it up as: Local postArgs(f); Object empty; postArgs = empty; seems to work. Playing around with a public copy constructor seems scarier here, given all the auto_ptr and what-not running around. Given that Linux distributions are starting to ship with GCC 3.4 as the default compiler, it seems like we should do something about this. But what? Index: util/test.h =================================================================== RCS file: /cvsroot/wheat/r1/util/test.h,v retrieving revision 1.10 diff -u -r1.10 test.h --- util/test.h 24 Dec 2004 20:40:21 -0000 1.10 +++ util/test.h 21 Jan 2005 16:40:16 -0000 @@ -139,8 +139,18 @@ #define CHECK_MSG(cond, message) \ pt::test::check(HERE, message, cond) +#if 0 #define CHECK_SAME(v, e) \ pt::test::check_same(HERE, #v, v, #e, e) +#else +/* Workaround bug/feature in GCC version Red Hat 3.4.2-6.fc3, which wanted to + invoke a copy constructor without the "location" temporary variable. */ +#define CHECK_SAME(v, e) \ + do { \ + pt::testlocation location(__FILE__, __LINE__, _called_from); \ + pt::test::check_same(location, #v, v, #e, e); \ + } while (0) +#endif #define CHECK_CONTAINS(needle, haystack) \ pt::test::check_contains(HERE, #needle, needle, #haystack, haystack) |
|
From: Kragen S. <ksi...@co...> - 2005-01-13 21:44:38
|
On Wed, 2005-01-12 at 13:24 -0800, Mark Lentczner wrote:
> Sure - add all of those buglets to the tracker on sourceforge. -- Until
> we write and run a story/task manage in Wheat running on WheatFarm - we
> just don't have a good spot to keep stuff. What would you all prefer
> in the short term:
> a) Use SF's tracker
> b) Keep it all in the Wiki
> c) Revive "CardFile", Glyphic's old web based task card system?
I anticipate that our bugs will quickly exceed the carrying capacity of
the wiki; I'd be happy with either (a) or (c), but for now I'll do (a).
> It seems that it is time for me to set up wheat-developer mailing list.
> Agreed?
Yes!
Therefore, upon reflection, stringAsString should be:
> Return
> stringAsString(Frame& f, int code)
> {
> Self self(f);
> return self.link();
> }
Hmm, I wonder whether the contract of as-string should include whether
it returns a new string or a link to an existing string (since code
that's expecting one can break in subtle ways if it gets the other), and
if so, which one it should be.
|
