Call for action

[Giancarlo Niccolai]

Hello people,

After last development round, the completion of the try/catch/finally
statement, the new engine has become stable enough to be a solid base
for 1.0.

The source is solidly commented for doxygen (contrariy to the old
version), and overall, context infos can be found at the 2 links
below:
http://www.niccolai.cc/index.php?itemid=431
http://www.freesoftwaremagazine.com/columns/falcon_virtual_machine_organic_virtual_machine_shown_practical_examples

If you want to lend a hand, take a look at the latest post on the
Falcon site home page and to our TODOs:

http://www.falconpl.org/index.ftd?page_id=sitewiki&prj_id=_falcon_site&sid=wiki&pwid=Home&wid=New%20Engine%3AIssues

We need help. If you think the project is interesting, hand out a few
spare hours and code in a bit.

Thanks to everyone,
Gian.

[Klaim - Joël Lamotte]

Hi,

I'm getting back a bit to Falcon to prepare getting back to my related project.

I wanted to know if 

http://falconpl.org/index.ftd?page_id=sitewiki&prj_id=_falcon_site&sid=wiki&pwid=Home&wid=Agenda

and/or 

http://www.falconpl.org/index.ftd?page_id=sitewiki&prj_id=_falcon_site&sid=wiki&pwid=Home&wid=New%20Engine%3AIssues

are "up to date" (to see if there are minor tasks I could help with).

The wiki really needs a last-change-date displayed on every page...

Klaim

[Giancarlo Niccolai]

The first link is totally outdated and mainly bogus, must be deeply reviewed.
The second link is absolutely OK. We're currently on this:

Module serialization. Requres to serialize and deserialize the tree structure, the items, and some dynamic data.

I consider the above preliminary to everything else. I am a few hours away from completing this. If you want to know more details, either jump in the chat or we can go more in depth here.

Gian.

[Klaim - Joël Lamotte]

I will not be able to get in the chat until wednesday I think but ok!

I need to dive in my old code and use of Falcon first and compare with the new engine use to make it at least compile.

Klaim

[Giancarlo Niccolai]

The new engine is a total rewrite -- at least for now -- except for some
very base code as the streams and the strings. 95% of the modules should
be compatible, when we get there.

Gian.

[Klaim - Joël Lamotte]

On Mon, Feb 13, 2012 at 19:22, Giancarlo Niccolai <g...@niccolai.cc> wrote:

The new engine is a total rewrite -- at least for now -- except for some
very base code as the streams and the strings. 95% of the modules should
be compatible, when we get there.

Yes, but I don't use any module so it's mostly my embedding code that I need to upgrade I guess.

Klaim 

[theguy]

can "static linking support" be added to agenda

Ashish

[Giancarlo Niccolai]

More than static linking support, better to work at module bundles ( like java JARs).

Gian.

[Paul Davey]

> Il giorno sabato 3 marzo 2012 06:03:01 UTC+1, theguy ha scritto:
>>
>> can "static linking support" be added to agenda
>>
>> Ashish
>>

Do you mean static linking of falcon itself?

If so this is possible already but is not helpfully exposed in the
build system and modules wont work statically linked.

[theguy]

ya, i mean static linking of falcon itself. Even if it is not exposed in build system, still what to do to get it done.

If we are linking a statically linked binary of LUA, then it does not disable the module support. It just does not allow externally (dynamically linkable) modules , but it still does allow those modules which have been themselves statically linked too with that statically linked binary of lua.

So why we can't make the modules to be statically linked  if possible, in case of falcon.

Ashish

[Paul Davey]

On Wed, Sep 5, 2012 at 7:39 AM, theguy <ashis...@gmail.com> wrote:
> ya, i mean static linking of falcon itself. Even if it is not exposed in
> build system, still what to do to get it done.

Well you need to build and link it as a static library instead of a
dynamic library.

>
> If we are linking a statically linked binary of LUA, then it does not
> disable the module support. It just does not allow externally (dynamically
> linkable) modules , but it still does allow those modules which have been
> themselves statically linked too with that statically linked binary of lua.
> So why we can't make the modules to be statically linked if possible, in
> case of falcon.

To be more specific, the things which wont work for modules if you
statically link them are for the old engine loading of modules and
also that the entry point for when they are DLLs is all named the same
so you would get a link error with them.
In addition in the old engine the module was set up in this entry
point function so to make them statically linkable they would need
some build system support and change the macro to some function of the
module name.
In the new engine the general way to define the module is to define a
module subclass which sets itself up in the constructor, and the DLL
entry point simply creates a module and returns it to the caller.

When statically linking modules into the program the person who is
embedding falcon is responsible for creating the modules and putting
them somewhere where they can be used. In this way it will be more
inconvenient to the embedder than dynamic linking but then I think the
reason you want it is for systems that forbid or don't support dynamic
linking.

Static linking does not prevent the modules from working necessarily,
it just adds a few extra constraints needed, such as having either no
entry point or a uniquely named one and require the user to be able to
inform the engine somehow of the modules, either linking them manually
or by some mechanism informing the module loader of their existence.

Paul