Yuku free message boards

Thanks optigon. >> Auv needs some work in this regard

Do you think, this would be a job appropriate for a total newbie in Wings and Erlang like me? I've some background in programming (since 1995 e.g. FORTH, C, Perl, Java and more) but not with any functional language (except some sniffing into Haskell). I mean, for that job, one would not have a need to understand/touch any of the AUV algorithms at all (my math would be too poor for that). It's more a "filling in the dots" job, isn't it?

Even then I for sure would need some help, where to start. I don't mean learning Erlang basics (e.g. syntax, pattern matching etc.), there are enough references on the net, here in the Programming forum and scorpius also has some pointers. But, as far as I know, Wings is one of the most advanced Erlang programs using some very clever tricks, especially in the menu code (if I remember right). And there are only few comments in the source.

What do you think? Best regards

Oops, I obviously misjudged that job. No surprise really, else one of you developers would have "filled in the blanks" along the way. So, for me, this will be a "my brain hurts" type ... but then, it hurts every day anyway . A first success for me was to compile and run my own version of 1.1.2 , so that I now can begin to experiment.

> I'd imagine that it would only involve adding an event_handler. ...
> So auv specific hks need to be context sensitive.

Yes, absolutely, hotkeys meant/defined for AUV shall only work, when the AUV window has the focus. Else they wouldn't be usefull and there would be hotkey clashes all the time with other parts of Wings. Currently (still from a user perspective) I see AUV as just another 'mode', similar to body/face/edge/vertex, just having it's own window. If I'm seriously wrong here, please tell me.

> you'll really like functional programming

Let me see, if I can get used to it and can figure out the event handling in Wings.

Best regards

>> That's excellent! Not an easy thing to do, that's for sure. What platform have you compiled Wings on?

I did it on XP and I found it really easy and well prepared, after I solved 3 pitfalls:

0. Setup:

• essentially followed the instructions in the source BUILD.win32 file, that suggests to install binary versions especially for ESDL (which contains a binary SDL too), so that I hadn't to compile neither SDL nor ESDL. But also have read your instructions in the Programming forum, which helped a lot.
• cygwin was no problem, I use it since a long time. Only basics and the GNU make are required however (I've much more installed, e.g. a cygwin gcc, but that isn't neccessary and did no harm).
• Erlang R13B installed under C:\Programme\erl5.7.1 (default of installation)
• didn't want the wings sources on C:, so I uncompressed them to D:\projekte\Wings3D\wings-1.1.2\*.* and the ESDL binary version to d:\projekte\Wings3D\esdl-1.0.1\*.* . That D: drive/partition caused trouble with MinGW later, see below.

1. Path pitfall (-vv again ):

Cygwin has a strange notion of pathes in trying to mimic a unix file system. A PATH environment variable set via Windows "C:\abc;D:\xyz" becomes automatically translated to a cygwin PATH of "/cygdrive/c/abc:/cygdrive/d/xyz" which is neccessary for cygwin shells (I use bash) to find any program in C:\abc or D:\xyz. But this automatic conversion is only done for the PATH environment variable, the ESDL_PATH remains unchanged. And one must know, that under UNIX/cygwin the '\' (backslash) is an escape character, that changes the meaning of the following character and to get a single backslash one has to write '\\'. But then cygwin also accepts a single forward slash '/' as a directory separator.

Same is true for Erlang and MinGW (that '/' as directory separator). However, otherwise both require Windows pathes having a drive/partion letter in front and can't handle these "/cygdrive/c/whatever" pathes.

So to avoid my pitfall: enter the PATH in Windows as usual (with backslash and drive letter in front) BUT BE SURE to write the ESDL_PATH as "D:/projekte/Wings3D/esdl-1.0.1" (with drive letter, but with forward slashes)! There might be other ways, but that is, what worked for me. After that, my compile went smoothly ... until MinGW was called.

2. MinGW pitfall:

MinGW essentially is a UNIX gcc (+more) but specially crafted to produce native Windows applications/dlls. In my case I installed it into C:\MinGW, as it's setup suggested (remember, my sources to compile are on D:). mingw32-gcc.exe was called successfully from the Wings Makefile (because I had setup the PATH to it), but then it couldn't find it's helper programs and include files (specifically 'cc1' and some standard header). A web search gave a hint: MinGW must be installed on the same drive/partition, as the sources to compile and in a top level directory. I'm sure, there are better ways to setup MinGW, but for me it was just some tool neccessary in the process of compiling Wings and currently I have no plans to use it otherwise.

So, I deinstalled it from C: and reinstalled it (just the basics including gcc) to D:\MinGW and changed the PATH to also point now to D:\MinGW\bin. Then my compile went smoothly without any error or warning (OK, there really is one warning wings_ogla_drv.c: In function `wings_file_start': wings_ogla_drv.c:151: warning: passing arg 3 of `gluTessCallback' from incompatible pointer type) which I consider to be harmless.

Thus: the Wings make files and sources are really well written. The path issue was my fault (optigon, you've pointed out the correct syntax already in the Programming forum). The MinGW issue is either again my fault (not setting it up correctly) or their fault (I heard other users having probs with it).

3. Line ending pitfall:

This one is a shame for me (and Erlang IMHO). When I tried to start my self compiled Wings 1.1.2 Erlang crashed completely (NOT Wings, Erlang). Turned out, that the shell script I wrote to start Wings had (accidentially) Windows line endings in it (because I used a Windows editor instead of vi). Other than that it looked exactly like the interactive command line as suggested by BUILD.win32:

werl -smp disable -pa $ESDL_PATH/ebin -pa c:/cygwin/home/bjorng/wings-1.0/ebin -run wings_start start_halt

Clearly my fault. But Erlang received that 'start_halt' as 'start_halt\r' ... and that simple, well known, line ending problem caused the whole Erlang system to crash?

WHHHOOO ... wasn't there a total break down of the german Telecom mobile servers lately? I dunno, what caused that and don't want to blame anyone. But imagining, that one single wrong line ending in millions of codelines might break a whole distributet system makes me shudder.

Back to Wings: you see, how easy it is to compile your own version?

>> ... Auv is a mini version of wings in some ways ... It seems that wpc_autouv.erl cmds do indeed begin with {auv,_}. So yes it is like a mode similar to v/e/f/b.

Yes and No. You pointed it out already, AUV sits on top of Wings somehow and has it's own v/e/f/b modes. Sorry, I must understand more, to comment qualified and come up with questions.

Thanks a lot optigon, for all your hints and pushing the Wings development forward and giving us great enhancements! Best regards

Thanks Bjorn, I'll be happy to add the essence of my findings to BUILD.win32. And I wanna do it the git way ... but I need to install git first and get used to it at least a little bit. Just am reading the docs (but I've used CVS/SVN before), so it will take some time. And thanks to clarify the \r issue which calms me down.

Two more questions though:

1. as far as I checked, ALL Wings sources are using UNIX line endings (except for *.bat files) also on windows (because that must be told the unawary windows user planning to edit)?
2. what about the character encoding of the *.lang files? E.g. the *_de.lang files seem to be in ANSI/ISO-8859-1, but the the *_pl.lang files are clearly in UTF-8. How does Erlang takes care of that? Would a byte order mark (BOM) be harmfull and to be avoided (the *_pl.lang files don't have BOM)?

Best regards