I noticed on a freshmeat.net announcement that there is a program called Cibyl that converters MIPS binaries into Java bytecode.

I wonder if using the fpc cross-compiler to mips-32 would allow FPC/Lazarus to leverage the converter in Cibyl to accomplish the same thing, but for FPC instead of C/C++.

To Quote: "Cibyl uses GCC to compile programs to MIPS binaries, and these are then translated into Java bytecode."

You mean http://nestedvm.ibex.org/ this ? I gotta take a look at it, it should be possible if the converter plays at binary level instead of source level. I wonder how it converts call to routines residing in dll? JNI?

leledumbo wrote

You mean http://nestedvm.ibex.org/ this ? I gotta take a look at it, it should be possible if the converter plays at binary level instead of source level. I wonder how it converts call to routines residing in dll? JNI?

It is not the same project. Just similar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110620/4eaea326/attachment.html>

I noticed on a freshmeat.net <http://freshmeat.net> announcement that there is a program called Cibyl that converters MIPS binaries into Java bytecode.

A closer look at Cibyl <http://code.google.com/p/cibyl/wiki/Cibyl> is not very encouraging, WRT FPC/Lazarus compatibility :-(

Since only C code can be converted, what IMO is a reasonable restriction (as I made for ToPas), this would mean that only subroutines can be converted, not classes and methods. This will apply to all such converters.

The sample code in above article suggest that a dedicated GUI interface #include <javax/microedition/lcdui.h> has to be used, and most probably also a Java related RTL.

This means that a convertable FPC/Lazarus application can *not* use the classes and components in FCL or LCL, it must not use classes at all :-(

I wonder if using the fpc cross-compiler to mips-32 would allow FPC/Lazarus to leverage the converter in Cibyl to accomplish the same thing, but for FPC instead of C/C++.

This may work, but only for non-OO code. Since the LCL is based on classes, no Cibyl/Java widgetset can be created and used in convertable code.

It would be easier[1] to add a Java target to FPC itself, and to make it use Java libraries instead of .dll or .so libraries. The language also would deserve modifications, because the built-in strings and other types must be replaced by the native Java types (using UTF-8). An application consequently would look more like Java code, with Pascal syntax only in statements.

[1] Where "easier" still means that this would be such a big task, that nobody honestly would ever implement a Java or .NET target for FPC.

DoDi

http://jasmin.sourceforge.net/)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110621/50cef111/attachment.html>

So.. things like the 'Jasmin' java assembler compiler are out also? (http://jasmin.sourceforge.net/)

Code generation is not enough. Imagine what Lazarus would be without classes, components, and all those other nice things. Even the basic functions (RTL) would look different, unless somebody writes wrappers around the Java libraries.

DoDi

I'm trying to figure out whether this bizarre behavior is a mistake on my side or a bug with Lazarus. I've been working on a project featuring the SynEdit component, using the FPC highlighter as a dummy highlighter while I was developing a new highlighter for a specific language my project is centered around. Everything was working fine until I was ready to start testing my own highlighter. At this point the highlighter is still unfinished and I am just including it as a unit in my project and using it as any other class rather than dealing with the complexities of registering it in Lazarus as a Design Time component. After I removed the references to TSynHighlighterPas and replacing them with my own, I started to run in to this odd problem. All of a sudden when attempting to build, FPC reported that it was unable to find the SynEdit unit. SynEdit is included as a dependency in the project inspector, and here's the bizarre part. After reporting that it cannot find the unit, Lazarus actually opens the SynEdit.pp file in the editor. What the hell does it mean it can't find it and then opens it in the editor. Hovering the mouse over the unit in the Uses block shows the correct location for the unit (/usr/lib/... on Linux, c:\lazarus\... on Windows). So I copied the files from my source directory in to my project directory, and then it was suddenly able to find the Unit, and reported the next unit TSynEditTypes or whatever missing. Even more bizarre, if I delete all references to SynEdit in my project, and attempt to create one from the component palette, it is now referencing my project directory as the location of the unit.

None of the search path for the units seem to have changed after adding the new highlighter, and as I stated before SynEdit is included as a dependency in the project inspector. I just don't understand why it all of a sudden can't find the SynEdit units all of a sudden after adding a single new unit to the project. I can understand why the problem goes away after I add them to my projects directory obviously, but why is it only having problems with the SynEdit units and not the rest of the LCL. I would appreciate it very much if someone could let me know what I'm doing wrong here, or if this is a bug I would gladly file a bug report for it.

This is happening on both the version 0.9.28.2 included in the Ubuntu 10.04 repos, and the 0.9.30 release available for win64.

Thank you,
David Riley

There is a difference between Lazarus and FPC finding it...

1) Do not copy the files from the SynEdit package to your path. never ever.
2) Do not add any -Fu -Fi or other custom path to your project, that points to synedit...

- In "project inspector", SynEdit is present as package under dependencies?
- Make sure you have only one version of FPC. As soon as 2 versions (even minor versions, even svn revisions) of FPC get's mixed, things go unexpected....
- Make sure, nowhere in your project, or in any path that you may have added yourself to the project, is a synedit.ppu (or any ppu for synedit*, except your highlighter)
- Compile with -va (and look add all+hidden msgs) to see where fpc looks for the file, and why they may be rejected. (a lot of output in msgs)

I assume you create the new highlighter in code? As it is not registered, you can not ue it on the form designer. (nor put it by hand into the lfm)

Yes, the highlighter is currently in code, I'm not quite ready to mess with registering it yet as it is still under heavy development and I'm more comfortable just having it as a separate unit in my project.

I've done some experimenting with just the highlighter unit and an empty project, and when I removed the {$I synedit.inc} line from the highlighter (I'm currently using none of the defines in the file anyway) everything compiled fine. So looking through the verbose output as you told me to, I found that the synedit.inc file is in the source directory or the synedit folder which is not in the search path. I also found that in that project that the compiler searched for synedit.pp instead of the compiled .ppu files in the units directory. So now at least I have a good workaround so I can continue development and testing on the highlighter.

Excuse my lack of knowledge on the way units work in Pascal, I'm still learning "The Pascal Way" which is very nice, but a bit different that what I'm used to. I'd imagine in this case it's probably best to create a separate project for the highlighter itself and compile it in to it's own unit and learn the process of registering a component in the ide? That way once I start finishing up the highlighter and add in the conditionals in the proper spots (for Delphi compatibility and such, like is featured in the other highlighters) I won't have to worry about the synedit.inc file messing up the search paths for the larger project.

Thank you very much for your help Martin, it is much appreciated, I think I have this figured out now, and I actually learned quite a bit in the process. Thanks again for your time.

Hm, interesting. Not sure why/how removing the SynEdit.inc does match up with your original description (but there are many possibilities

For the inc file you could use -Fi, but I would advice taking a copy of the file (if at all ever needed, which I doubt)

First of all: The $IFDEF SYN_LAZARUS are a relict from old days. They are in the (very slow) process of being removed). SynEdit only compiles with them enabled. IT does not compile without them anyway. The SynEdit in Lazarus does not currently compile in can make your Highlighter compilable in Delphi of course. That would make sense if you want to use it with the original SynEdit (sourceforge, non Lazarus version). However the Lazarus SynEdit has a modified interface for it's highlighters. So there would be a bit of extra work, to maintain the differences.

-------------
About you original problem:

SynEdit is a package, The Lazarus IDE has at sometime compiled this package. In the synedit folder (like in any package, like in the RTl, or even your project) you find a folder (usually named "units" or "lib") containing ppu files.
The ppu files are only usable for the EXACT version of FPC that created them.
If your project uses SynEdit, the in Lazarus, it must depend on the package synedit. This will add the path to the ppu files. And only to the ppu files. FPC does not (and should no need to ) know about the pas files

However if you do something in your project, that makes fpc believe that the SynEdit.ppu is outdated, then FPC wants to recompile it. But as Lazarus has fully intentional not told FPC were the source is, fpc can't recompile it => unit Synedit not found (lazarus of course knows were it is)

One reason why fpc may believe it want to recompile it, is if fpc sees a unit that is used by synedit and is newer than synedit. (This does not apply to the inc file )

e.g ig you COPIED SynEditHighlighter.pas (the base class of the highlighters) to your project.
Then FPC sees the new SynEditHighlighter.ppu, and it says Synedit.ppu depends on this, and since the SynEditHighlighter.ppu is newer (changed), then Synedit must be recompiled.

The include file does not produce a ppu file (it's embedded into each file that uses it).
It also is NOT your own highlighter. Since in Synedit.pas, there is no "uses yourhighlighter". SynEdit does not depend on your highlighter.

So your initial error sounded like you copied a file (other than the inc) from the synedit directory to your project.

Of course, instead of having copied a file, you may also have added an include path to your project, that added the synedit directory as search path for pascal files to your project. Anopther thing that should bnever ever be done.
With such an include path, if compiling your highlighter, files used by your highlighter (like the base class SynEditHighlighter.pas) will be recompiled, and create a ppu file in your project (same as with the copied pas file)...

So in case like this. look at your projects "lib" folder and find any ppu that should not be there. Then find out why it is there....

David Riley wrote

I've done some experimenting with just the highlighter unit and an empty project, and when I removed the {$I synedit.inc} line from the highlighter (I'm currently using none of the defines in the file anyway)

That looks rather unusual to me, using this include. The sysnedit.inc does not belong to you, it is part of the implementation section of (I assume) synedit.pp.

I don't think it is good practice to include it in another unit.

Bart

That's a good point, the reason it was in my source file was because I started the highlighter based on the Visual Basic highlighter because mine is for the Free Basic language and I figured it would be a good start. It just contains some defines for conditional compilation and I've since removed the file as I don't really need it while I'm developing and testing. I doubt I'll be using it at all as I couldn't care less about Delphi or C++ Builder compatibility for my project.

Thank you very much for all of your help Martin, I have my unit compiling properly and learned some new do's and don'ts. I'm now looking forward to the hopefully not too painful process of working in code folding and auto-complete in to the editor. Should be fun. ;) Anyway, just wanted to say thanks again, in all my years I've never run in to a community as friendly and helpful as the FPC/Lazarus team.