Wouldn't Cygwin help here?
I belive gcc is for Windows as well, so it should be possible...

It does not work at the moment, both line and column determination. IMHO, it should be rooted away, or perhaps make this behaviour after a switch (like fpc -h). It is the only app that does this, and it confuses me as user...
And sure, "less" or "more" is much more powerful for this than you will ever want to code into FPC. "more" is available even for DOS - and people running FPC from commandline are most likely to know what "more" and pipe is :-)

But this sort of thing (i18n) is a lot of drudgery, noone seems to want to do that and maintain that ...
I believe you should use glibc for POSIX systems, and specific Win32 bindings for Windows, just like Lazarus does for Win32/GTK/Qt

IIRC, glibc is present in MacOS X, too. For Win32, I would think glibc from Cygwin project could be linked as well...

Michal

I doubt I can, since

"x must be a tool, not a purpose in itself", is almost a cliche in Dutch :-)

Actually I once wrote a critical article about portability and code-reuse for Stacks internal magazine once, and the above sentence could have been in it.

Maybe I should rewrite/update it (and translate to English), and sent it to Rosa, or put it on my private webpage.

I don't know, several programs which cause a segmentation fault on other ppc machines
freeze (no ping, no keyboard, no kernel panic, it simply freezes) my linux/ppc. It happens with the 2.2.20 kernel and all flavors which I tried of
2.4.18 and 2.4.19. Now I know why journaling file systems are needed :)

I wouldn't recommend this. Sounds like a lot of work. IMHO, on Unix this should be handled by LC_ALL (and similar) environment variables. If someone wants always a different language just for this application, he can always start it like this:

export LC_ALL=cs_CZ; ./lazarus

i.e., I recommend no explicit language switching inside IDE. Of course, I assume that FPC has some means of runtime resourcestring substitution from compiled .po files like other gettext (C) programs under Linux have?

Michal

Looks like they forgot to split content/presentation layers. Looks like a major design flaw :-)
How would you rate DocBook with this respect?

Michal

Sure, nothing against. It would be the only application to support it, except maybe for Mozilla, which requires restart anyway. It's not only message strings (which, going through Translate function, would slow the IDE down), localization has to include fonts (cyrillic, different character encodings), bi-di (arabic), sorting, uppercasing, shortcuts, number formatting, etc. (heck, even default paper size for printing :-)

MHO:

The nice thing about Unix, is its modularity. This is what I love about Unix, and hate about Windows (lack of). As I see it, Free Pascal and potentially Lazarus tend to do a lot of things on its own, still essentially the same way as others. Sometimes it is needed for crossplatformness, sometimes just because someone feels like it. This is not a rant, I myself am curious to see where it leads - maybe it will show up as a more powerful direction. As I see it, though, there is a lot of duplication and incosistencies with the rest of the operating system and its applications (read Linux here) as a result.

It's a number of these little things, for example:

<rant mode>

- just type fpc - it lists 40 lines and wants Enter - why? I can use fpc|more or fpc|less, I have a bigger terminal, and it bugs me to hit Enter several times
- sorting, uppercasing, lowercasing procs do not take into account locale. Sure, it is a lot of work, but it's already in glibc (that's why it may take about 20MB installed in the system), which all (not just C) program rely on. FPC does not relay to glibc and rather duplicates the work, so we end up with unusable sorting for anyone else except Englishmen.
- [I may be misinformed here] - why fpcmake? Why not standard GNU autoconf/make stuff? It is meant to be programming language independent, right?
- rewriting of stuff that is in Win32 (I don't mean compatibility functions, rather desktop integration - stock icons, workspace, etc.) where GNOME or KDE was created for and fits the bill.

</rant mode>

Please don't react to the above points, they are only illustrative and I don't want to start a flamewar on any of these points.

The point is, we should always think about whether and how it is implemented in the OS(es), and follow those practices, if possible. If we need to change something, then ask lib/OS authors first, and only if they don't understand our needs, only *then* duplicate their work. That's the spirit of open source as I see it.

And one day, perhaps, we will not see Lazarus executable 9MB large and counting...

Michal

Well this all is in the CBT/WBT eLearning world. This is of course the major focus of my business. As Marco pointed out the fanatics, in this case the PHD egg heads who sit around and dream up concepts without really having to use them, created the SCORM model.

http://www.adlnet.org if you are really interested.

Courseware refers to training courses or learning/references products. The idea of SCORM is to make every little piece of a course reusable. That means every screen, graphic, media clip is reusable outside of the current course. So for example assume I have a course that teaches how to code in Perl. In the course there is a page that explains what a "Regular Expression" is. I have to design the course, it's flow, it's images everything about it to be totally independent on anything else in the course. That is so if someone else is writing a course on PHP they could just tell the manifest control file that it should just reuse the page on Regular Expressions found in the Perl course. Or maybe it just wants to use the image I used on my page or maybe just the audio. Anyway you should get the idea. Pages/concepts/media should be totally independent of the course they are in so that they can be plugged in and reused anywhere else without having to do anything to them.

RIGHT. Welcome to the real world. It doesn't happen or even work.

The above model doesn't take into account screen design, colors, control buttons, etc. etc. etc. So my Regular Expression page could have a blue background to match the course design but the PHP could use brown. So they would have to take the content and recode it to match the PHP course anyway. The whole thing is an egg head pipe dream.

The biggest problem is that I, as a contractor, don't have access to my clients base of courseware so I don't even know what already exists to attempt to reuse it in the first place. So EVERYTHING ALWAYS gets recreated.

The whole thing is a joke. :-\

It's a pity. But I've placed such a change (localized some dialogs, pallete, initialization part of idecomp made a proc) in two files (one is 1st part, another is second)
http://www.ussr.to/Russia/vvi/lazaloc1.zip
http://www.ussr.to/Russia/vvi/lazaloc2.zip

On Mon, 16 Sep 2002 17:11:04 +0200
"Florian Klaempfl" wrote

This is def. a problem for Lazarus.. Of course the incomplete FCL is even more of an issue(for OSX that is, most other *nix stuff will be minimal I'd imagine), but I imagine once the compiler is more stable this will start filling in quickly.

and some other calling convention related stuff are show stoppers for larger programs. Of course, a lot debugging must be done which is a pain on my ppc box, user programs can crash it :(.

Well once it's a little more functional on the PPC, we can start testing out Lazarus on Linux for PPC, and I'm sure you'll start getting all sorts of bug reports back then. ;) I have a farely fast mac I just installed OS X on, and I have Linux for it as well, so once it becomes a little more stable, I'll start seeing how well the version from CVS holds up against basic Lazarus stuff, linux first, then as the FCL becomes more complete for MacOSX I can start testing it out there using a X-Server and the GTK libs. I just wish I knew more about compilers and could help speed up the process...

Andrew

_________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

So, it includes changing (moving strings to rst). Editor options dialog had (without any localization) a bug (and have it, if it haven't been fixed from Saturday): it is impossible to change font style (bold etc). It need manual xml editing. It was difficult to internationalize, as many text is applied in array consts and initialization. I've made a temporary hack - moving initialization to a proc - in idecomp. But it would be a good idea to load all internationalization not from constrctor, but from a unit initialization, which must not be the last in unit lists.

95 per cent of the compiler side part are implemented. Things like complete support of nested procedures
and some other calling convention related stuff are show stoppers for larger programs. Of course,
a lot debugging must be done which is a pain on my ppc box, user programs can crash it :(.

:-) No.

I resize my terminal (gnome-terminal) any way I see fit. "more", "less", "info", "man", Midnight Commander, all work just fine at any size.

I though glibc == libc these days.
Looks like locale aware sorting won't be available anytime soon. But FPC is not the only kid on the block... I recently wrote some simple code in C for Firebird 1.x (great SQL engine, originally from Borland), and they do the same... rewriting all intl stuff from scratch. Tons of code. :-(
Looks like every major app does things again, and again... There goes code reuse. (sigh)

Michal

Michal Bukovjan wrote

Looks like they forgot to split content/presentation layers. Looks like a major design flaw :-)

Ahhhh. You nailed it right on the head. :-)

How would you rate DocBook with this respect?

You know I don't know a thing about DocBook. I have yet to use it. There have been times when I said to myself I really ought to sit down and learn about it but the time never seemed to materialize. :-\

So, it includes changing (moving strings to rst). Editor options dialog had (without any localization) a bug (and have it, if it haven't been fixed from Saturday): it is impossible to change font style (bold etc).

It seems, you are right.
I have fixed the TCheckBox.Checked bug during OnClick. But some syntax hilighting types reacts not instantly to clicks. But after clicking on and off it works.

Mattias

Oooooooo. Thank you.

I am dealing with SCORM and will be doing a presentation of the problems that come with trying to implement courseware using it. The above quote will be beautiful. It explains the problem wonderfully and in just a few simple words. Thanks.

* SCORM (Sharable Content Object Reference Model)

seen fpc/powerpc gets working so a Lazarus for MacOS is possible for Aqua the desktop integration is probably different.

What's the status of fpc/powerpc?

Mattias

Yes. we support gettext.

Michael.

So, it includes changing (moving strings to rst).

Thx. But plz send diffs instead of whole files, so they can be merged with other changes.

Editor options dialog had (without any localization) a bug (and have it, if it haven't been fixed from Saturday): it is impossible to change font style (bold etc). It need manual xml editing.

The bug is TComboBox.OnClick. It is called before the gtk-interface switches the state of the Checked property. I will fix it in the next days.

It was difficult to internationalize, as many text is applied in array consts and initialization.

True. That was not very clever by me. But it is not very difficult to change it.

I've made a temporary hack - moving initialization to a proc - in idecomp. But it would be a good idea to load all internationalization not from constrctor, but from a unit initialization, which must not be the last in unit lists.

It doesn't matter for the IDE. The IDE should support language course this needs Translate procs for every dialog.

Mattias

It is very little extra work compared to localization lazarus.

Hmm. Lazarus is a visual thing. IMO a good IDE should never need to restart and there should be a graphical frontend for _every_ setting. And it's easy to implement.

i.e., I recommend no explicit language switching inside IDE.

It's open source. If one implements it and it does not bite, it will go into the source. :)

Of course, I assume that FPC has some means of runtime resourcestring substitution from compiled .po files like other gettext (C) programs under Linux have?

Mattias

I want to see Lazarus / FPC application to share as much code with the system as possible and reasonable. Hmm, even my Emacs 21.2 has only 4 megabytes and it can play mp3, too :-)

Michal

Marco, quickly, you should trademark this ;)

And what does this beast do ?
What does courseware do, for that matter ?

Michael.

Do you want to add 130 MB Cygwin to the 10 MB Lazarus?

I belive gcc is for Windows as well, so it should be possible...

We already use cygwin _parts_, e.g. for the debugger. But it should be as little as possible. Distributions are _huge_

Then your terminal is behaving badly. Are lines and columns variables set correctly?

Connecting to glibc is in practice also a can of worms. Note that glibc only exists on Linux, Dos, Windows and OS/2 (afaik). *BSD has an own libc, so does Solaris etc.

I believe you should use glibc for POSIX systems, and specific Win32 bindings for Windows, just like Lazarus does for Win32/GTK/Qt

Why ? We can't even parse its headers. It would make porting even harder.

We now base the *nix ports directly on a POSIX interface (either kernel interface, glue code for "special" operating systems, or libc (e.g. embedded systems). This works very nice. I recently did the basic OpenBSD port in two evenings.

IIRC, glibc is present in MacOS X, too. For Win32, I would think glibc from Cygwin project could be linked as well...

I would assume MacOS X to use FreeBSD's libc, since its userland is derived from it.

Most of them either use Ncurses (like e.g. the IDE), or have a lot of extra code to fix this. Has nothing to do with libc.

>I would assume MacOS X to use FreeBSD's libc, since its userland is derived >from it. > I though glibc == libc these days.

No. Only Linux, cygwin/mingw/djgpp and maybe BeOS and OS/2 afaik.

Looks like locale aware sorting won't be available anytime soon.

The current way is the right one, as long as it is pluggable.

But FPC is not the only kid on the block... I recently wrote some simple code in C for Firebird 1.x (great SQL engine, originally from Borland), and they do the same... rewriting all intl stuff from scratch. Tons of code. :-(

Why do you think this is? Code reuse is quite difficult in practice (while fanatics step over problems easily).

It is just like in the real world. Taking a new one is often less work than fixing the old one.

Code reuse must be a tool, not a purpose in itself.

Common for a all points: your arguments may be true for Linux but FPC runs on a lot of other platforms...

<rant mode> - just type fpc - it lists 40 lines and wants Enter - why?

For people don't know fpc or for lazy people :)

I can use fpc|more or fpc|less, I have a bigger terminal, and it bugs me to hit Enter several times

Do a fpc -h|more and you'll be fine.

I think the fpc solution is much more user friendly than the default behavior of unix tools, i.e.
an integrated "more". Though the terminal line determination may be buggy.

A glibc based solution might be unusable for non unix systems thus we want a generic solution. The linux/unix
solution might use glibc based code. OTOH we decided a long time ago that the core rtl won't use glibc.

- [I may be misinformed here] - why fpcmake? Why not standard GNU autoconf/make stuff? It is meant to be programming language independent, right?

1. make doesn't take care of interdepended units
2. making everything with make is too slow just compare the build times of C programs and of pascal programs :)
3. see above

- rewriting of stuff that is in Win32 (I don't mean compatibility functions, rather desktop integration - stock icons, workspace, etc.) where GNOME or KDE was created for and fits the bill.

The goal of lazarus is to run on as much as possible GUIes so GNOME or KDE isn't enough. As you may have
seen fpc/powerpc gets working so a Lazarus for MacOS is possible for Aqua the desktop integration is
probably different.

</rant mode> Please don't react to the above points, they are only illustrative and I don't want to start a flamewar on any of these points.

I'll react however :)

:)

Why that ?

Mattias

The big problem with reusability, is that it is perceived to have no additional cost, which is typical for beginner and non- programmers. And also that reimplementation with an example in the hand is much faster.

Fact is that most software (and other designs) are often only re-used 4 times at the uttermost, and mosttimes less.

So if
Rx=the reimplement time for the nth platform;
Tx=the time for creating the global portable library and Px=the time for porting the global portable library to the xth platform then

R1+R2+R3+R4>=Tx+P1+P2+P3+P4

for portability to be worthwhile. Most projects except some really _major_ ones, loose on this.
(note that probably R1>>>R2>R3>R4 and Tx>>P1>P2>P3>P4)

One of course can make similar equations for maintenance etc, and make comments like: "portable projects are also not infinitisemaly portable. One sees complete rewrites per major version in portable projects too"

So the idea of "One codebase till eternity" is also nonsense. ------------

A striking example is the message from one of the Stonybrook compiler writers.

He redraws all widgets per platform of their IDE instead of creating a unified library.

Why? Because it cost him 2 days max to redraw it, and you all know how much time is invested to create a multi-platform widget set :-)

Use "fpc -h" and it will not wait.

- [I may be misinformed here] - why fpcmake? Why not standard GNU autoconf/make stuff? It is meant to be programming language independent, right?

- autoconf/automake is unix (POSIX shell) specific
- autoconf is mostly used to detect the capabilities of the C compiler. We don't need all that kind of things for fpc.
- The speed of autoconf automake is very slow
- You need a lot of other tools and files

And one day, perhaps, we will not see Lazarus executable 9MB large and counting...

What do you want a lazarus.so of 8,990 mb and a 10kb lazarus executable?

Marco van de Voort wrote

The big problem with reusability, is that it is perceived to have no additional cost, which is typical for beginner and non- programmers. And also that reimplementation with an example in the hand is much faster.

I have a case in point at this very moment. I have a course that I completed for a client. It had 59 files of html, js, gif, and jpg. They totaled 758K in size. It would actually fit on a floppy.

Since delivery the client decided they wanted to use the same look and feel of another course which of course uses the SCORM/AICC layout and control. So they sent me a CD which has another course on it and said that it should look like this one. They felt that since this one was already done I should be able to just reuse the code and ... hey I would be finished.

Well of course I just can't reuse the code, I have to totally throw out everything I did and rewrite it to use this other companies structure, which will take me at least a week to figure out. Then I have to add in all of the overhead LMS control files. So if I just take my above code data I have to add an additional 370 files at a total of 2.1 Meg to deliver the exact same thing and it will cost the client the same amount they already paid me for the course plus more just so that it is in a reusable format. That will never be reused. :-\

Talk about selling someone a pig in a poke.