ferite-user — ferite user mailing list

Re: [ferite-user] Script Execution Problems

[Chris R. <ch...@fe...>]

Hi!

Sorry for the exceedingly late reply. Can you tell me which version
of ferite you are using ? Was it cvs ? Was it release ? If it was
release which version was it ? What version of Cygwin are you using ?

Hope I can help,

Chris

(I missed the email due to my main machine dying about the tine it
was sent)

--
Chris Ross
ch...@da... -- http://www.darkrock.co.uk



On 26 Feb 2006, at 07:45, Andrew Gallant wrote:

> Hello,
>
> I've successfully compiled Ferite on Cygwin, however when I go to
> execute a simple Hello World script (as demonstrated on
> http://ferite.org), I get the following output:
>
> ferite hello.fe
> [ferite: compile]
> Error: Unable to find script module 'stream'
> Error: Unable to find module 'stream'
> Error: Can't compile included file
> "/usr/local/lib/ferite/module-source/std.fec", error on line 30
> Error: Can't compile included file
> "/usr/local/lib/ferite/module-source/sys.fec", error on line 30
> Error: Unable to find module 'sys'
> Error: Can't compile included file
> "/usr/local/lib/ferite/module-source/console.fec", error on line 1
> Error: Unable to find module 'console'
> Error: Fatal error compiling script "/home/Andrew/myscripts/hello.fe"
>
> It should be noted that I have also ran "make install" for each =20
> module as well.
>
> Thanks for any help you may be able to give me,
> Andrew
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting =20
> language
> that extends applications into web and mobile media. Attend the =20
> live webcast
> and join the prime developer group breaking into this new coding =20
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642=

> _______________________________________________
> ferite-user mailing list
> fer...@li...
> https://lists.sourceforge.net/lists/listinfo/ferite-user

[ferite-user] Script Execution Problems

[Andrew G. <ja...@gm...>]

Hello,

I've successfully compiled Ferite on Cygwin, however when I go to
execute a simple Hello World script (as demonstrated on
http://ferite.org), I get the following output:

ferite hello.fe
[ferite: compile]
Error: Unable to find script module 'stream'
Error: Unable to find module 'stream'
Error: Can't compile included file
"/usr/local/lib/ferite/module-source/std.fec", error on line 30
Error: Can't compile included file
"/usr/local/lib/ferite/module-source/sys.fec", error on line 30
Error: Unable to find module 'sys'
Error: Can't compile included file
"/usr/local/lib/ferite/module-source/console.fec", error on line 1
Error: Unable to find module 'console'
Error: Fatal error compiling script "/home/Andrew/myscripts/hello.fe"

It should be noted that I have also ran "make install" for each module as w=
ell.

Thanks for any help you may be able to give me,
Andrew

Re: [ferite-user] Re: Re: Warning on every script

[Chris R. <ch...@fe...>]

Ok, I have fixed the warning in cvs ferite.

Thanks for the heads up WRT embedding ferite. There are a number of =20
great suggestions there which are more than likely to fall into the =20
next version of ferite (1.3), once I have gotten 1.1 out of the door,

Thanks,

Chris

--
Chris Ross
ch...@da... -- http://www.darkrock.co.uk



On 10 Feb 2006, at 02:04, Andre de Leiradella wrote:

> >The reason this happens is because you need to compile with -
> >DENABLE_THREADING
>
> But I don't want threads! And the warning is rather strange to me, =20
> looks like some ferite script internal to the engine is being =20
> compiled...
>
> >
> >The warning is there to let people know that it is not possible =20
> to  >use the built
> >in thread keywords because there is not threading.
>
> I wasn't using threads.
>
> >
> >I will add an option to the command line program to suppress =20
> warnings.
>
> Is there an option to capture all output to stdout and stderr in a =20
> function so I can show warnings and errors in dialog boxes for =20
> example?
>
> >
> >Chris
> >
> >PS. How did you compile it ? Can I have some instructions ? Does =20
> it  >create native
> >Windows DLLs ?
>
> I (ferite-1.0.2):
>
> 1) commented the "#define getcwd _getcwd" in aphex_directory.c
> 2) commented the "#include <sys/time.h>" in aphex_thread.c
> 3) changed the definition of fepwrap to "#define fepwrap() 1" in =20
> ferite_scanner.c
>
> #1 causes an error during link, it seems that bcc likes getcwd.
> #2 is because the header isn't found in bcc, and it appears that =20
> it's not needed to compile ferite with it.
> #3 is because later in ferite_scanner.c the macro is called without =20=

> arguments, causing the pre-processor to abort.
>
> With those changes I managed to create a static library which I =20
> called ferite.lib.
>
> After that I wrote a console.fec file just to be able to get some =20
> output and see if ferite was working:
>
> namespace Console {
>    native function print(string s) {
>        ferite_get_parameters(params, 1, &s);
>        printf("%s", s->data);
>    }
>      function println(string s) {
>        print(s);
>        print("\n");
>    }
> }
>
> I then changed test/main.c to include "Console_header.h" and call =20
> ferite_Console_register, compiled Console_*.c, main.c and linked =20
> the object files against ferite.lib to get an executable.
>
> About DLLs, I didn't create any for three reasons (although I think =20=

> it wouldn't be hard to do it):
>
> 1) I was trying to use ferite in place of Lua as an embedded =20
> language in FullMoon, a Moray plugin that enables users to write =20
> plugins in script language. As the plugin is already a DLL, I =20
> wanted it to be self-contained, and I also didn't need any of the =20
> modules that come with ferite. (I didn't even try to compile the =20
> modules)
> 2) I've had many problems under windows due to missing DLLs, so I =20
> became uncomfortable with applications built of an executable and =20
> lots of DLLs. I statically link everything whenever I can.
> 3) Windows applications most of the time like to put their DLLs =20
> inside a folder together with their executable. If I use some other =20=

> application's ferite.dll and user chooses to uninstall it, FullMoon =20=

> would stop working.
>
> I understand that ferite is not meant to be an embeddable scripting =20=

> language like Lua; it's primary objective is to be a language which =20=

> you can use to develop applications, a "stand-alone" language. But =20
> if you want to make it easier to use ferite as an embeddable =20
> language, I can point some things that I think would help, in the =20
> risk of being flamed by people much more experienced in ferite, C =20
> and the embedded world than me (and please feel free to just ignore =20=

> me):
>
> 1) Lua is a library that can load, compile and run scripts.
>
> The loading of scripts is made through an abstraction of an input =20
> stream of bytes. I, as the "embeddeder", have the responsibility to =20=

> provide Lua with a C structure initialized to read bytes from =20
> wherever I want, a file, a socket, memory. Lua doesn't know from =20
> where the scripts are being loaded. There is a auxiliary and =20
> optional library that provides a way to load scripts from the file =20
> system and from C strings for those who need it and don't want to =20
> write those functionalities by their own.
>
> Lua engine doesn't need to know anything about the environment it's =20=

> running in, nor library paths. The compilation and running of =20
> scripts don't need any interaction with the OS (unless you call =20
> native functions that call the OS, of course). I think that this =20
> abstraction could benefit ferite; write a input stream system and =20
> let users write code to read scripts from where they need, using =20
> library paths *if* they need to. As ferite can import other =20
> scripts, a call back user-defined function could be used. It would =20
> have the responsibility to, given the script name, return an input =20
> stream from where the script could be read.
>
> Loading native modules (DLLs, .so etc.) could also be delegated to =20
> a user-defined function. This mean that aphex and triton would be a =20=

> problem of the "embeddeder". Of course you could write input =20
> streams and code to load shared objects for a number of platforms =20
> in order to make ferite easier to start playing with. But those who =20=

> don't need it would have the chance to ignore it. I had problems =20
> the first time I tried to compile ferite because I wrote a triton =20
> version that just returned errors on every call to it. I believed =20
> that it wouldn't hurt since I wasn't trying to load any module but =20
> for my surprise the engine refused to run with a message related to =20=

> not being able to load modules or initializing triton (I don't =20
> remember the exact message). I also started implementing an aphex =20
> version that uses user-defined functions and userdata pointers to =20
> enable ferite to load scripts from anywhere more easily, but there =20
> was too much to know about ferite internals before I could do it.
>
> Abstracted input streams are also good to implement pre-processors =20
> and to implement the reading from compressed files (or blocks of =20
> memory) etc. I once wrote a library to Lua that had the ability to =20
> read from FILE*, file descriptors, memory blocks and C strings. I =20
> also wrote "filter" streams that could process data coming from the =20=

> underlying stream before passing it to Lua. That way I could load a =20=

> bzip2-compressed memory block or a gzipped file in the file system =20
> or being downloaded from a socket.
>
> Threads may be a problem, and I'm not experienced enough with =20
> ferite to say how they could be handled to satisfy those who need =20
> and those who don't need it. Making them always available could be =20
> a solution, but the code is os-specific and would make the engine =20
> bigger.
>
> 2) Command line arguments
>
> If I want to make my Pocket PC boot a ferite based OS to replace =20
> Pocket Windows, I wouldn't have argc and argv to give to the engine =20=

> so it can configure itself. Same thing happens with embedded =20
> languages. I could fake them, but I think that it's better to =20
> provide one or more API functions or some arguments to ferite_init =20
> that could be used to configure the engine. The command line =20
> options parsing, if any, is a responsibility of the "embeddeder".
>
> 3) Warnings and errors
>
> The loading, compilation and running of scripts shouldn't send any =20
> messages to stdout and stderr (unless the script calls native =20
> functions wrote by the "embeddeder" that do it). They should =20
> instead return error codes to the caller, and the caller does with =20
> it whatever it wants to (dump to stderr, open up a dialog box, =20
> ignore it). Or ferite could have an user-defined error function =20
> that receives the error message.
>
> Of course changing ferite to be more embeddable wouldn't mean that =20
> it couldn't be used to deploy applications fully written in it. One =20=

> could write a main.c that embeds the ferite engine and provides all =20=

> functions needed to load scripts and native modules from the file =20
> system, using various path to search for them, and with a number of =20=

> pre-built modules. This is exactly what LuaCheia does (http://=20
> luacheia.lua-users.org/).
>
> Ok, that's everything I can remember. Unfortunately I had to look =20
> for another scripting language to use with FullMoon, because after =20
> compiling ferite I found that a protocol can't extend another =20
> protocol like interfaces can extend another interface in Java. In =20
> FullMoon, I need, for example, to create a protocol called =20
> "Streamable" that marks objects that must store their state in the =20
> scene file when the user saves the scene in Moray. And I also have =20
> a "Configurable" protocol, which should extend "Streamable", =20
> because only "streamable" objects can be configured. If there is a =20
> way to do it with ferite please let me know.
>
> Oh, another thing that I see as a plus is the boolean type and the =20
> ability to use class and protocol names as type definition for =20
> variables, arguments and instance and class properties. Ferite =20
> already does type checking on compile time on numbers and strings =20
> (I like string being a primitive type by the way), so why have a =20
> generic "object" type that can receive instances of any class and =20
> make programs more susceptible to errors? This would make checks =20
> for the class of an object unnecessary.
>
> Regards,
>
> Andr=E9 de Leiradella
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through =20
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD =20
> SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=103432&bid#0486&dat=121642=

> _______________________________________________
> ferite-user mailing list
> fer...@li...
> https://lists.sourceforge.net/lists/listinfo/ferite-user

Re: [ferite-user] dbi-ferite-module-1.0.0

[Chris R. <ch...@fe...>]

Sorry for the late reply, have been very busy.

This means that the configure script can't locate the ferite-config
program. If you have installed ferite, please make sure that ferite/ 
prefix/bin
is in the path environment variable,

Chris

--
Chris Ross
ch...@da... -- http://www.darkrock.co.uk



On 11 Feb 2006, at 12:43, Stig Melsom wrote:

> Hi, I'm trying to install the dbi-ferite-module and keep getting  
> this really annoying error message.
>
> *** The ferite-config script could not be found. This script
> *** needs to be in the PATH, or should be specified using
> *** the --with-ferite-prefix option to configure.
> configure: error: You should have ferite 1.0.0 installed for this  
> to work.
>
> I have no idea of what to do, so can someone please help me out??
>
>
> btw. ferite kicks ass... but this is about the cleanest, most user  
> friendly scripting language i have ever seen...
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> ferite-user mailing list
> fer...@li...
> https://lists.sourceforge.net/lists/listinfo/ferite-user

[ferite-user] dbi-ferite-module-1.0.0

[Stig M. <sti...@gm...>]

Hi, I'm trying to install the dbi-ferite-module and keep getting this  
really annoying error message.

*** The ferite-config script could not be found. This script
*** needs to be in the PATH, or should be specified using
*** the --with-ferite-prefix option to configure.
configure: error: You should have ferite 1.0.0 installed for this to  
work.

I have no idea of what to do, so can someone please help me out??


btw. ferite kicks ass... but this is about the cleanest, most user  
friendly scripting language i have ever seen...

[ferite-user] Re: Re: Warning on every script

[Andre de L. <lei...@bi...>]

 >The reason this happens is because you need to compile with -
 >DENABLE_THREADING

But I don't want threads! And the warning is rather strange to me, looks=20
like some ferite script internal to the engine is being compiled...

 >
 >The warning is there to let people know that it is not possible to =20
 >use the built
 >in thread keywords because there is not threading.

I wasn't using threads.

 >
 >I will add an option to the command line program to suppress warnings.

Is there an option to capture all output to stdout and stderr in a=20
function so I can show warnings and errors in dialog boxes for example?

 >
 >Chris
 >
 >PS. How did you compile it ? Can I have some instructions ? Does it =20
 >create native
 >Windows DLLs ?

I (ferite-1.0.2):

1) commented the "#define getcwd _getcwd" in aphex_directory.c
2) commented the "#include <sys/time.h>" in aphex_thread.c
3) changed the definition of fepwrap to "#define fepwrap() 1" in=20
ferite_scanner.c

#1 causes an error during link, it seems that bcc likes getcwd.
#2 is because the header isn't found in bcc, and it appears that it's=20
not needed to compile ferite with it.
#3 is because later in ferite_scanner.c the macro is called without=20
arguments, causing the pre-processor to abort.

With those changes I managed to create a static library which I called=20
ferite.lib.

After that I wrote a console.fec file just to be able to get some output=20
and see if ferite was working:

namespace Console {
    native function print(string s) {
        ferite_get_parameters(params, 1, &s);
        printf("%s", s->data);
    }
  =20
    function println(string s) {
        print(s);
        print("\n");
    }
}

I then changed test/main.c to include "Console_header.h" and call=20
ferite_Console_register, compiled Console_*.c, main.c and linked the=20
object files against ferite.lib to get an executable.

About DLLs, I didn't create any for three reasons (although I think it=20
wouldn't be hard to do it):

1) I was trying to use ferite in place of Lua as an embedded language in=20
FullMoon, a Moray plugin that enables users to write plugins in script=20
language. As the plugin is already a DLL, I wanted it to be=20
self-contained, and I also didn't need any of the modules that come with=20
ferite. (I didn't even try to compile the modules)
2) I've had many problems under windows due to missing DLLs, so I became=20
uncomfortable with applications built of an executable and lots of DLLs.=20
I statically link everything whenever I can.
3) Windows applications most of the time like to put their DLLs inside a=20
folder together with their executable. If I use some other application's=20
ferite.dll and user chooses to uninstall it, FullMoon would stop working.

I understand that ferite is not meant to be an embeddable scripting=20
language like Lua; it's primary objective is to be a language which you=20
can use to develop applications, a "stand-alone" language. But if you=20
want to make it easier to use ferite as an embeddable language, I can=20
point some things that I think would help, in the risk of being flamed=20
by people much more experienced in ferite, C and the embedded world than=20
me (and please feel free to just ignore me):

1) Lua is a library that can load, compile and run scripts.

The loading of scripts is made through an abstraction of an input stream=20
of bytes. I, as the "embeddeder", have the responsibility to provide Lua=20
with a C structure initialized to read bytes from wherever I want, a=20
file, a socket, memory. Lua doesn't know from where the scripts are=20
being loaded. There is a auxiliary and optional library that provides a=20
way to load scripts from the file system and from C strings for those=20
who need it and don't want to write those functionalities by their own.

Lua engine doesn't need to know anything about the environment it's=20
running in, nor library paths. The compilation and running of scripts=20
don't need any interaction with the OS (unless you call native functions=20
that call the OS, of course). I think that this abstraction could=20
benefit ferite; write a input stream system and let users write code to=20
read scripts from where they need, using library paths *if* they need=20
to. As ferite can import other scripts, a call back user-defined=20
function could be used. It would have the responsibility to, given the=20
script name, return an input stream from where the script could be read.

Loading native modules (DLLs, .so etc.) could also be delegated to a=20
user-defined function. This mean that aphex and triton would be a=20
problem of the "embeddeder". Of course you could write input streams and=20
code to load shared objects for a number of platforms in order to make=20
ferite easier to start playing with. But those who don't need it would=20
have the chance to ignore it. I had problems the first time I tried to=20
compile ferite because I wrote a triton version that just returned=20
errors on every call to it. I believed that it wouldn't hurt since I=20
wasn't trying to load any module but for my surprise the engine refused=20
to run with a message related to not being able to load modules or=20
initializing triton (I don't remember the exact message). I also started=20
implementing an aphex version that uses user-defined functions and=20
userdata pointers to enable ferite to load scripts from anywhere more=20
easily, but there was too much to know about ferite internals before I=20
could do it.

Abstracted input streams are also good to implement pre-processors and=20
to implement the reading from compressed files (or blocks of memory)=20
etc. I once wrote a library to Lua that had the ability to read from=20
FILE*, file descriptors, memory blocks and C strings. I also wrote=20
"filter" streams that could process data coming from the underlying=20
stream before passing it to Lua. That way I could load a=20
bzip2-compressed memory block or a gzipped file in the file system or=20
being downloaded from a socket.

Threads may be a problem, and I'm not experienced enough with ferite to=20
say how they could be handled to satisfy those who need and those who=20
don't need it. Making them always available could be a solution, but the=20
code is os-specific and would make the engine bigger.

2) Command line arguments

If I want to make my Pocket PC boot a ferite based OS to replace Pocket=20
Windows, I wouldn't have argc and argv to give to the engine so it can=20
configure itself. Same thing happens with embedded languages. I could=20
fake them, but I think that it's better to provide one or more API=20
functions or some arguments to ferite_init that could be used to=20
configure the engine. The command line options parsing, if any, is a=20
responsibility of the "embeddeder".

3) Warnings and errors

The loading, compilation and running of scripts shouldn't send any=20
messages to stdout and stderr (unless the script calls native functions=20
wrote by the "embeddeder" that do it). They should instead return error=20
codes to the caller, and the caller does with it whatever it wants to=20
(dump to stderr, open up a dialog box, ignore it). Or ferite could have=20
an user-defined error function that receives the error message.

Of course changing ferite to be more embeddable wouldn't mean that it=20
couldn't be used to deploy applications fully written in it. One could=20
write a main.c that embeds the ferite engine and provides all functions=20
needed to load scripts and native modules from the file system, using=20
various path to search for them, and with a number of pre-built modules.=20
This is exactly what LuaCheia does (http://luacheia.lua-users.org/).

Ok, that's everything I can remember. Unfortunately I had to look for=20
another scripting language to use with FullMoon, because after compiling=20
ferite I found that a protocol can't extend another protocol like=20
interfaces can extend another interface in Java. In FullMoon, I need,=20
for example, to create a protocol called "Streamable" that marks objects=20
that must store their state in the scene file when the user saves the=20
scene in Moray. And I also have a "Configurable" protocol, which should=20
extend "Streamable", because only "streamable" objects can be=20
configured. If there is a way to do it with ferite please let me know.

Oh, another thing that I see as a plus is the boolean type and the=20
ability to use class and protocol names as type definition for=20
variables, arguments and instance and class properties. Ferite already=20
does type checking on compile time on numbers and strings (I like string=20
being a primitive type by the way), so why have a generic "object" type=20
that can receive instances of any class and make programs more=20
susceptible to errors? This would make checks for the class of an object=20
unnecessary.

Regards,

Andr=E9 de Leiradella

[ferite-user] Modules question

[Henderson, M. D <mic...@lm...>]

I am looking at the modules list on Sourceforce (
http://sourceforge.net/project/showfiles.php?group_id=8427 ). I noticed
that the release numbers weren't bumped when the ferite core was bumped
to 1.0.2. I'm the type that gets warm fuzzies when all of the numbers
match, but I'm also grown up enough to realize that doing so is
administrivia.

Is there going to be (or is there already and I'm just missing it) a way
to know that a module will work with a given release of the ferite core?
I haven't seen anything that that states how the core revision number is
bumped if there's an API change. I'm assuming that it's a change to the
minor and that the major changes if backwards compatibity is broken.

An example in the developer world would be if I were writing the Grand
Unified Flubber Interface and I *know* that it won't work with a core
prior to 1.0.2. Should I just do a simple check against the version
string or is there a better, safer way?

Thanks,
Mike

[ferite-user] Scoping Question

[Henderson, M. D <mic...@lm...>]

I think that ferite's scoping needs a little more documentation because
it is a little inconsistent. In the following example, the variable i is
created and placed in the global scope:

  uses "console";
  for( number i = 0; i < 5; i++ ) {
    Console.println( "\tloop i is $i" );
  }
  Console.println( "i is $i" );

The output makes that pretty clear:
        loop i is 0
        loop i is 1
        loop i is 2
        loop i is 3
        loop i is 4
  i is 5

However, if the variable i already exists, then the for loop operates on
a local copy, not the one in the outer scope:
  uses "console";
  number i = 2;
  Console.println( "i is $i" );
  for( number i = 0; i < 5; i++ ) {
    Console.println( "\tloop i is $i" );
  }
  Console.println( "i is $i" );

The output shows that the variable is not changed:
  i is 2
        loop i is 0
        loop i is 1
        loop i is 2
        loop i is 3
        loop i is 4
  i is 2

The document is a little unclear in that it states "that there will be
no impact on the surrounding code" (
http://ferite.org/docs/html-manuals/manual/#for-loop.title ). I don't
know if this behaviour will change with the planned upgrades to the core
ferite, so is it worth clarifying this?

Mike

Re: [ferite-user] compile errors

[Chris R. <ch...@fe...>]

I will have a look and release 1.0.1 this weekend. I have
been suffering from personal problems that have been taking
up my time.

Chris

--
personal: ch...@da... , http://www.darkrock.co.uk
university: ct...@cs... , http://www.cs.bham.ac.uk/~ctr/
ferite programming language: http://www.ferite.org


On 7 Jul 2005, at 00:09, tony summerfelt wrote:


> a few days ago i had a hd failure, so instead of putting money into  
> a new drive, i just picked up a new machine...
>
> it runs winxp sp2, and a brand new install of cygwin.
>
> grabbed the ferite source from cvs:
>
> cvs -d:pserver:ano...@cv...:/cvsroot/ferite login
> cvs -z3 -d:pserver:ano...@cv...:/cvsroot/ferite co  
> ferite
>
> and ran ./autogen.sh, then make. looks like the same error as last  
> time
>
> ==========================================================
> Creating library file: .libs/libferitestream.dll.a
> Info: resolving _ferite_free by linking to __imp__ferite_free (auto- 
> import) ar cru .libs/libferitestream.a  util_stream.o
> ranlib .libs/libferitestream.a
> creating libferitestream.la
> (cd .libs && rm -f libferitestream.la && ln -s ../ 
> libferitestream.la libferitestream.la)
> ../../builder/builder -m stream ../../modules/stream/stream.fec
> builder: processing filename /home/Compaq_Owner/ferite/modules/ 
> stream/stream.fec
>
> Error: Library Loader: Can't find module 'stream.lib'
> Error: Unable to find script module 'string'
> Error: Unable to find module 'string'
> Error: Parse Error: on line 800 in "/home/Compaq_Owner/ferite/ 
> modules/stream/stream.fec"
> Error:    (syntax error, unexpected '{')
> Error: Fatal error compiling script "/home/Compaq_Owner/ferite/ 
> modules/stream/stream.fec"
> if /bin/bash ../../libtool --tag=CC --mode=compile gcc -D_REENTRANT  
> -DUSE_PTHREAD -DTHREAD_SAFE -I. -I. -I../.. -I../../include -I/usr/ 
> local/include -I.     -DH
> AVE_CONFIG_HEADER -g -O2 -MT stream_core.lo -MD -MP -MF ".deps/ 
> stream_core.Tpo"
> -c -o stream_core.lo stream_core.c; \
> then mv -f ".deps/stream_core.Tpo" ".deps/stream_core.Plo"; else rm  
> -f ".deps/stream_core.Tpo"; exit 1; fi
>  gcc -D_REENTRANT -DUSE_PTHREAD -DTHREAD_SAFE -I. -I. -I../.. - 
> I../../include -I/usr/local/include -I. -DHAVE_CONFIG_HEADER -g -O2  
> -MT stream_core.lo -MD -MP -M
> F .deps/stream_core.Tpo -c stream_core.c  -DPIC -o .libs/stream_core.o
> gcc: stream_core.c: No such file or directory
> gcc: no input files
> make[3]: *** [stream_core.lo] Error 1
> make[3]: Leaving directory `/home/Compaq_Owner/ferite/modules/stream'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home/Compaq_Owner/ferite/modules'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/Compaq_Owner/ferite'
> make: *** [all] Error 2
> ==========================================================
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> ferite-user mailing list
> fer...@li...
> https://lists.sourceforge.net/lists/listinfo/ferite-user
>
>

[ferite-user] compile errors

[tony s. <sno...@ho...>]

a few days ago i had a hd failure, so instead of putting money into a 
new drive, i just picked up a new machine...

it runs winxp sp2, and a brand new install of cygwin.

grabbed the ferite source from cvs:

cvs -d:pserver:ano...@cv...:/cvsroot/ferite login
cvs -z3 -d:pserver:ano...@cv...:/cvsroot/ferite co ferite

and ran ./autogen.sh, then make. looks like the same error as last time

==========================================================
Creating library file: .libs/libferitestream.dll.a
Info: resolving _ferite_free by linking to __imp__ferite_free 
(auto-import) ar cru .libs/libferitestream.a  util_stream.o
ranlib .libs/libferitestream.a
creating libferitestream.la
(cd .libs && rm -f libferitestream.la && ln -s ../libferitestream.la 
libferitestream.la)
../../builder/builder -m stream ../../modules/stream/stream.fec
builder: processing filename 
/home/Compaq_Owner/ferite/modules/stream/stream.fec

Error: Library Loader: Can't find module 'stream.lib'
Error: Unable to find script module 'string'
Error: Unable to find module 'string'
Error: Parse Error: on line 800 in 
"/home/Compaq_Owner/ferite/modules/stream/stream.fec"
Error:    (syntax error, unexpected '{')
Error: Fatal error compiling script 
"/home/Compaq_Owner/ferite/modules/stream/stream.fec"
if /bin/bash ../../libtool --tag=CC --mode=compile gcc -D_REENTRANT 
-DUSE_PTHREAD -DTHREAD_SAFE -I. -I. -I../.. -I../../include 
-I/usr/local/include -I.     -DH
AVE_CONFIG_HEADER -g -O2 -MT stream_core.lo -MD -MP -MF 
".deps/stream_core.Tpo"
-c -o stream_core.lo stream_core.c; \
then mv -f ".deps/stream_core.Tpo" ".deps/stream_core.Plo"; else rm -f 
".deps/stream_core.Tpo"; exit 1; fi
  gcc -D_REENTRANT -DUSE_PTHREAD -DTHREAD_SAFE -I. -I. -I../.. 
-I../../include -I/usr/local/include -I. -DHAVE_CONFIG_HEADER -g -O2 
-MT stream_core.lo -MD -MP -M
F .deps/stream_core.Tpo -c stream_core.c  -DPIC -o .libs/stream_core.o
gcc: stream_core.c: No such file or directory
gcc: no input files
make[3]: *** [stream_core.lo] Error 1
make[3]: Leaving directory `/home/Compaq_Owner/ferite/modules/stream'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/Compaq_Owner/ferite/modules'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Compaq_Owner/ferite'
make: *** [all] Error 2
==========================================================

[ferite-user] cygwin error

[tony s. <sno...@ho...>]

went to the web page, saw this:

cvs -z3 checkout -r FERITE_1_0_BRANCH ferite

ran autogen.sh and make again.

same error as last time: i've included a bit more to see if it helps:

gcc -shared  .libs/util_stream.o  -L/home/tonys/ferite/src 
-L/usr/local/lib /home/tonys/ferite/src/.libs/libferite.dll.a 
-L/usr/lib  -o .libs/cygferitestream-1.dll -Wl,--image-base=0x10000000 
-Wl,--out-implib,.libs/libferitestream.dll.a
Creating library file: .libs/libferitestream.dll.a
Info: resolving _ferite_free by linking to __imp__ferite_free 
(auto-import)
ar cru .libs/libferitestream.a  util_stream.o
ranlib .libs/libferitestream.a
creating libferitestream.la
(cd .libs && rm -f libferitestream.la && ln -s ../libferitestream.la 
libferitestream.la) ../../builder/builder -m stream 
../../modules/stream/stream.fec
builder: processing filename  /home/tonys/ferite/modules/stream/stream.fec
Error: Library Loader: Can't find module 'stream.lib'
Error: Unable to find script module 'string'
Error: Unable to find module 'string'
Error: Parse Error: on line 800 in 
"/home/tonys/ferite/modules/stream/stream.fec"
Error:    (syntax error, unexpected '{')
Error: Fatal error compiling script 
"/home/tonys/ferite/modules/stream/stream.fec"
if /bin/sh ../../libtool --tag=CC --mode=compile gcc -D_REENTRANT 
-DUSE_PTHREAD
-DTHREAD_SAFE -I. -I. -I../.. -I../../include -I/usr/local/include -I. 
     -DHAVE_CONFIG_HEADER -g -O2 -MT stream_core.lo -MD -MP -MF 
".deps/stream_core.Tpo" -c
  -o stream_core.lo stream_core.c; \
then mv -f ".deps/stream_core.Tpo" ".deps/stream_core.Plo"; else rm -f 
".deps/stream_core.Tpo"; exit 1; fi
  gcc -D_REENTRANT -DUSE_PTHREAD -DTHREAD_SAFE -I. -I. -I../.. 
-I../../include -I
/usr/local/include -I. -DHAVE_CONFIG_HEADER -g -O2 -MT stream_core.lo 
-MD -MP -MF .deps/stream_core.Tpo -c stream_core.c  -DPIC -o 
.libs/stream_core.o
gcc: stream_core.c: No such file or directory
gcc: no input files
make[3]: *** [stream_core.lo] Error 1
make[3]: Leaving directory `/home/tonys/ferite/modules/stream'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/tonys/ferite/modules'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/tonys/ferite'
make: *** [all] Error 2

-- 
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

[ferite-user] Re: Re: Re: Re: cygwin compile errors

[tony s. <sno...@ho...>]

> I agree that it is odd that you are having these issues. What
> versions of autoconf, automake and libtool are you using ?

autoconf 2.5
automake 1.9?
libtool 1.5

-- 
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

Re: [ferite-user] Re: Re: cygwin compile errors

[Chris R. <ch...@fe...>]

No, I simply made a couple of makefile changes and then built
and installed it.

I agree that it is odd that you are having these issues. What
versions of autoconf, automake and libtool are you using ?

Chris

--
personal: ch...@da... , http://www.darkrock.co.uk
university: ct...@cs... , http://www.cs.bham.ac.uk/~ctr/
ferite programming language: http://www.ferite.org


On 17 Jun 2005, at 14:24, tony summerfelt wrote:

>
>
>> I have successfully built ferite on cygwin.
>>
>
> did you have to do anything special to get it to build?
>
> after a cvs update i run ./autogen.sh
>
> after that's run through i run make, and during beginning of the  
> make it runs configure again...
>
> i've gotten a little farther through the compile after each update,  
> but i still don't have a ferite executable.
>
>
>
> -- 
> http://home.cogeco.ca/~tsummerfelt1
> telnet://ventedspleen.dyndns.org
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> ferite-user mailing list
> fer...@li...
> https://lists.sourceforge.net/lists/listinfo/ferite-user
>

[ferite-user] Re: Re: cygwin compile errors

[tony s. <sno...@ho...>]

> I have successfully built ferite on cygwin.

did you have to do anything special to get it to build?

after a cvs update i run ./autogen.sh

after that's run through i run make, and during beginning of the make 
it runs configure again...

i've gotten a little farther through the compile after each update, 
but i still don't have a ferite executable.



-- 
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

Re: [ferite-user] Development Document and File System Paths

[Christian M. S. <cm...@ce...>]

Hello, 

On Thursday 16 June 2005 18.36, Chris Ross wrote:
> Hi,
>
> I have put up the initial version of the development document, please
> read and comment.
>
>      http://www.ferite.org/developer.html

I think it might be good to also add a section about the plans to make ferite 
more charset aware. 


>
> I have stumbled across a problem that I would like to garner peoples
> opinions.
>
> So far ferite has only run under platforms where the path delimiter
> has been '/'. With the work I have done with using MinGW has opened a
> can of worms. It builds windows native programs which means that paths
> need to be of the form c:\foo.
>
> So the problem is how should paths be handled ?
>
> - We could have it so that paths are handled in their native fashion
>    but this means that people who write scripts need to be aware of the
>    path delimiters on the platform. For two different types this isn't
>    a big problem but could be an issue depending on platforms in the
>    future.
>
> - All paths take on the / as a delimiter and have aphex convert to the
>    platform specific path.
>

I think the best idea is to use / as a delimiter and let aphex convert it. 


-- 
Christian M. Stamgren | Head of development
Direct: +46 (0)8-410 446 01 | Mobile: +46 (0)708-50 74 01
E-mail: cm...@ce...
Internet: www.cention.se
 
Cention AB | PO Box 3326 | SE-103 66 Stockholm | Sweden
Visiting address: Birger Jarlsgatan 20 | SE-114 34 Stockholm
Phone: +46 (0)8-410 446 00 | Fax: +46 (0)8-656 49 00

[ferite-user] Re: Development Document and File System Paths

[tony s. <sno...@ho...>]

> So the problem is how should paths be handled ?

I worked with early versions of perl under dos. I think most people 
who program on dos/windows with  languages that originated on a *nix 
platform are use to using c:\\path\\to\\file or c:/path/to/file. I 
never use c:\path\to\file as it's been problematic...


-- 
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

[ferite-user] Re: [Ferite-devel] Development Document and File System Paths

[carl <ca...@ca...>]

Hi,

> So the problem is how should paths be handled ?

Remember, MacOS 8/9 used colon (:) as their path delimiters.  I'm not 
sure if it's at all likely Ferite will run on that OS, but there could 
be others I am not aware of that don't use / or \.

> - We could have it so that paths are handled in their native fashion
>   but this means that people who write scripts need to be aware of the
>   path delimiters on the platform. For two different types this isn't
>   a big problem but could be an issue depending on platforms in the
>   future.

Not a good idea, in my opinion.

> - All paths take on the / as a delimiter and have aphex convert to the
>   platform specific path.

This gets my vote, because of the below reason, but also because it 
seems the cleanest way to do it.  At least developers from any of the 
UNIXes will be aware of the need to escape any /'s in filenames.  In 
this case, the rule is simple - Use / in paths, and escape them for use 
in filenames.

> - Have / and \ as path delimiters and have aphex deal with the paths.

Remember, you can have / and \ as part of a valid filename in most 
(all?) UNIXes, so this isn't a great idea.  Developers would need to 
escape one or the other, depending on which platform you are running on, 
but you would only know at runtime, meaning platform specific code.

Regards,
Carl.

[ferite-user] Re: [Ferite-devel] Development Document and File System Paths

[atani <at...@at...>]

On Jun 16, 2005, at 9:36 AM, Chris Ross wrote:

> So the problem is how should paths be handled ?
> - All paths take on the / as a delimiter and have aphex convert to the
>   platform specific path.

I vote for all ferite user-code should use a single delimiter for  
path and have the interpreter deal with it accordingly.  That said, I  
have yet to find an API on windows that does not already handle / as  
a path separator.  This of course excludes programs like cmd.exe  
which use / as a CLI option delimiter.

Also, you could put a method that handles proper platform separators  
as well which might be nice if the compiler/interpreter supports both  
\ and /.  Additionally the path separator is either : or ; depending  
on platform as well.

Mike

[ferite-user] Development Document and File System Paths

[Chris R. <ch...@fe...>]

Hi,

I have put up the initial version of the development document, please
read and comment.

     http://www.ferite.org/developer.html

I have stumbled across a problem that I would like to garner peoples
opinions.

So far ferite has only run under platforms where the path delimiter
has been '/'. With the work I have done with using MinGW has opened a
can of worms. It builds windows native programs which means that paths
need to be of the form c:\foo.

So the problem is how should paths be handled ?

- We could have it so that paths are handled in their native fashion
   but this means that people who write scripts need to be aware of the
   path delimiters on the platform. For two different types this isn't
   a big problem but could be an issue depending on platforms in the
   future.

- All paths take on the / as a delimiter and have aphex convert to the
   platform specific path.

- Have / and \ as path delimiters and have aphex deal with the paths.

Ideas ?

Chris

--
personal: ch...@da... , http://www.darkrock.co.uk
university: ct...@cs... , http://www.cs.bham.ac.uk/~ctr/
ferite programming language: http://www.ferite.org

[ferite-user] cywin compile errors

[tony s. <sno...@ho...>]

updated from cvs at: [Jun 15/ 2005 -- 02:37 pm]

got a little bit farther in the compile than last time. this is the 
error I'm getting now:

creating libferitestream.la
(cd .libs && rm -f libferitestream.la && ln -s ../libferitestream.la 
libferitest
ream.la)
../../builder/builder -m stream ../../modules/stream/stream.fec
builder: processing filename /home/tonys/ferite/modules/stream/stream.fec
Error: Library Loader: Can't find module 'stream.lib'
Error: Unable to find script module 'string'
Error: Unable to find module 'string'
Error: Parse Error: on line 800 in 
"/home/tonys/ferite/modules/stream/stream.fec
"
Error:    (syntax error, unexpected '{')
Error: Fatal error compiling script 
"/home/tonys/ferite/modules/stream/stream.fe
c"
if /bin/s  ../../libtool --tag=CC --mode=compile gcc -D_REENTRANT 
-DUSE_PTHREAD
-DTHREAD_SAFE -I. -I. -I../.. -I../../include -I/usr/local/include -I. 
     -DHAV
E_CONFIG_HEADER -g -O2 -MT stream_core.lo -MD -MP -MF 
".deps/stream_core.Tpo" -c
  -o stream_core.lo stream_core.c; \
then mv -f ".deps/stream_core.Tpo" ".deps/stream_core.Plo"; else rm -f 
".deps/st
ream_core.Tpo"; exit 1; fi
  gcc -D_REENTRANT -DUSE_PTHREAD -DTHREAD_SAFE -I. -I. -I../.. 
-I../../include -I/usr/local/include -I. -DHAVE_CONFIG_HEADER -g -O2 
-MT stream_core.lo -MD -MP -MF .deps/stream_core.Tpo -c stream_core.c 
  -DPIC -o .libs/stream_core.o
gcc: stream_core.c: No such file or directory
gcc: no input files
make[3]: *** [stream_core.lo] Error 1
make[3]: Leaving directory `/home/tonys/ferite/modules/stream'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/tonys/ferite/modules'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/tonys/ferite'
make: *** [all] Error 2
-- 
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

Re: [ferite-user] cygwin compile errors

[Chris R. <ch...@da...>]

Hi,

I have successfully built ferite on cygwin.

I will release 1.0.1 in a couple of days once I have also finished
the port to MinGW.

Regards,

Chris

--
personal: ch...@da... , http://www.darkrock.co.uk
university: ct...@cs... , http://www.cs.bham.ac.uk/~ctr/
ferite programming language: http://www.ferite.org


On 13 Jun 2005, at 14:32, tony summerfelt wrote:


> just updated from cvs a few minutes ago. got a little farther in  
> the compile. it stopped here:
>
> make[3]: Leaving directory `/home/tonys/ferite/modules/stream'
> make[3]: Entering directory `/home/tonys/ferite/modules/stream'
> ../../builder/builder -m stream ../../modules/stream/stream.fec
> builder: processing filename /home/tonys/ferite/modules/stream/ 
> stream.fec
> Error: Library Loader: Can't find module 'stream.lib'
> Error: Unable to find script module 'string'
> Error: Unable to find module 'string'
> Error: Parse Error: on line 800 in "/home/tonys/ferite/modules/ 
> stream/stream.fec
> "
> Error:    (syntax error, unexpected '{')
> Error: Fatal error compiling script "/home/tonys/ferite/modules/ 
> stream/stream.fe
> c"
> if /bin/sh ../../libtool --tag=CC --mode=compile gcc -D_REENTRANT - 
> DUSE_PTHREAD
> -DTHREAD_SAFE -I. -I. -I../.. -I../../include -I/usr/local/include - 
> I.     -g -O
> 2 -MT stream_core.lo -MD -MP -MF ".deps/stream_core.Tpo" -c -o  
> stream_core.lo st
> ream_core.c; \
> then mv -f ".deps/stream_core.Tpo" ".deps/stream_core.Plo"; else rm  
> -f ".deps/st
> ream_core.Tpo"; exit 1; fi
>  gcc -D_REENTRANT -DUSE_PTHREAD -DTHREAD_SAFE -I. -I. -I../.. - 
> I../../include -I
> /usr/local/include -I. -g -O2 -MT stream_core.lo -MD -MP -MF .deps/ 
> stream_core.T
> po -c stream_core.c  -DPIC -o .libs/stream_core.o
> gcc: stream_core.c: No such file or directory
> gcc: no input files
> make[3]: *** [stream_core.lo] Error 1
> make[3]: Leaving directory `/home/tonys/ferite/modules/stream'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home/tonys/ferite/modules'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/tonys/ferite'
> make: *** [all] Error 2
> -- 
> http://home.cogeco.ca/~tsummerfelt1
> telnet://ventedspleen.dyndns.org
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can  
> you shotput
> a projector? How fast can you ride your desk chair down the office  
> luge track?
> If you want to score the big prize, get to know the little guy.   
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> ferite-user mailing list
> fer...@li...
> https://lists.sourceforge.net/lists/listinfo/ferite-user
>
>

[ferite-user] cygwin compile errors

[tony s. <sno...@ho...>]

just updated from cvs a few minutes ago. got a little farther in the 
compile. it stopped here:

make[3]: Leaving directory `/home/tonys/ferite/modules/stream'
make[3]: Entering directory `/home/tonys/ferite/modules/stream'
../../builder/builder -m stream ../../modules/stream/stream.fec
builder: processing filename /home/tonys/ferite/modules/stream/stream.fec
Error: Library Loader: Can't find module 'stream.lib'
Error: Unable to find script module 'string'
Error: Unable to find module 'string'
Error: Parse Error: on line 800 in 
"/home/tonys/ferite/modules/stream/stream.fec
"
Error:    (syntax error, unexpected '{')
Error: Fatal error compiling script 
"/home/tonys/ferite/modules/stream/stream.fe
c"
if /bin/sh ../../libtool --tag=CC --mode=compile gcc -D_REENTRANT 
-DUSE_PTHREAD
-DTHREAD_SAFE -I. -I. -I../.. -I../../include -I/usr/local/include -I. 
     -g -O
2 -MT stream_core.lo -MD -MP -MF ".deps/stream_core.Tpo" -c -o 
stream_core.lo st
ream_core.c; \
then mv -f ".deps/stream_core.Tpo" ".deps/stream_core.Plo"; else rm -f 
".deps/st
ream_core.Tpo"; exit 1; fi
  gcc -D_REENTRANT -DUSE_PTHREAD -DTHREAD_SAFE -I. -I. -I../.. 
-I../../include -I
/usr/local/include -I. -g -O2 -MT stream_core.lo -MD -MP -MF 
.deps/stream_core.T
po -c stream_core.c  -DPIC -o .libs/stream_core.o
gcc: stream_core.c: No such file or directory
gcc: no input files
make[3]: *** [stream_core.lo] Error 1
make[3]: Leaving directory `/home/tonys/ferite/modules/stream'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/tonys/ferite/modules'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/tonys/ferite'
make: *** [all] Error 2
-- 
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

[ferite-user] cygwin compile error

[tony s. <sno...@ho...>]

after the cvs update, the compile got this far:


*** Warning: This system can not link to static lib archive 
/home/tonys/ferite/src/libferite.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
libtool: link: warning: undefined symbols not allowed in 
i686-pc-cygwin shared libraries
ar cru .libs/libferitestream.a  util_stream.o
ranlib .libs/libferitestream.a
creating libferitestream.la
(cd .libs && rm -f libferitestream.la && ln -s ../libferitestream.la 
libferitestream.la)
../../builder/builder -m stream ../../modules/stream/stream.fec
builder: processing filename /home/tonys/ferite/modules/stream/stream.fec
Error: Library Loader: Can't find module 'stream.lib'
Error: Unable to find script module 'string'
Error: Unable to find module 'string'
Error: Parse Error: on line 800 in 
"/home/tonys/ferite/modules/stream/stream.fec
"
Error:    (syntax error, unexpected '{')
Error: Fatal error compiling script 
"/home/tonys/ferite/modules/stream/stream.fec"
if /bin/sh ../../libtool --tag=CC --mode=compile gcc -D_REENTRANT 
-DUSE_PTHREAD
-DTHREAD_SAFE -I. -I. -I../.. -I../../include -I/usr/local/include -I. 
     -g -O
2 -MT stream_core.lo -MD -MP -MF ".deps/stream_core.Tpo" -c -o 
stream_core.lo st
ream_core.c; \
then mv -f ".deps/stream_core.Tpo" ".deps/stream_core.Plo"; else rm -f 
".deps/st
ream_core.Tpo"; exit 1; fi
  gcc -D_REENTRANT -DUSE_PTHREAD -DTHREAD_SAFE -I. -I. -I../.. 
-I../../include -I
/usr/local/include -I. -g -O2 -MT stream_core.lo -MD -MP -MF 
.deps/stream_core.T
po -c stream_core.c  -DPIC -o .libs/stream_core.o
gcc: stream_core.c: No such file or directory
gcc: no input files
make[3]: *** [stream_core.lo] Error 1
make[3]: Leaving directory `/home/tonys/ferite/modules/stream'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/tonys/ferite/modules'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/tonys/ferite'
make: *** [all] Error 2

-- 
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

[ferite-user] Re: [Re: [Re: Re: feritte compile error on cygwin

[tony s. <sno...@ho...>]

> Are you sure you are using Ferite from up to date CVS. 

I grabbed it from the cvs, about 20 min. before the timestamp of my 
message...

I will update now, and try again...

> struct timeval should be inside <sys/time.h> at least it is on all the systems 
> I currently work on (Linux and diffrent Unixes).

from cygwin sys/time.h on my system:

struct timeval {
   long tv_sec;
   long tv_usec;
};

> If struct timeval and gettimeofday() is prototyped in some other header under 
> Cygwin please let me know.

int _EXFUN(gettimeofday, (struct timeval *__p, struct timezone *__z))

is in the same header...

I'll update and try again...
-- 
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

Re: [ferite-user] Re: Re: feritte compile error on cygwin

[Chris R. <ch...@da...>]

I will take a look at this problem later today when I have access
to a nice fast Win2k box.

I will patch 1.0 and release 1.0.1 this week.

Chris

--
personal: ch...@da... , http://www.darkrock.co.uk
university: ct...@cs... , http://www.cs.bham.ac.uk/~ctr/
ferite programming language: http://www.ferite.org


On 12 Jun 2005, at 09:53, Christian M. Stamgren wrote:

> Hello,
>
> Are you sure you are using Ferite from up to date CVS.
> I did a small commit yesterday that should resolve the issue.
> But I don't have Cygwin so I cant really test the result of the fix.
>
> struct timeval should be inside <sys/time.h> at least it is on all  
> the systems
> I currently work on (Linux and diffrent Unixes).
>
> If struct timeval and gettimeofday() is prototyped in some other  
> header under
> Cygwin please let me know.
>
>
> Regards,
>
> //Christian
>
> On Sunday 12 June 2005 01.53, tony summerfelt wrote:
>
>>> Could you please test compile the code from Ferite CVS and see if  
>>> this
>>> issue is resolved?
>>>
>>
>> cvs version had the same error:
>>
>> gcc -DAUTOLOAD_CORE -D_REENTRANT -DUSE_PTHREAD -DTHREAD_SAFE -I. -I.
>> -I../../.. -I../../../libs/aphex/include  -I../../../include
>> -I/usr/local/include -I/usr/local/include     -g -O2 -c -o a
>> phex_thread.lo aphex_thread.c
>>   gcc -DAUTOLOAD_CORE -D_REENTRANT -DUSE_PTHREAD -DTHREAD_SAFE -I.  
>> -I.
>> -I../../..  -I../../../libs/aphex/include -I../../../include
>> -I/usr/local/include -I/usr/lo
>> cal/include -g -O2 -c aphex_thread.c  -DPIC -o .libs/aphex_thread.o
>> aphex_thread.c: In function `aphex_event_timedwait':
>> aphex_thread.c:307: error: storage size of 'tp' isn't known
>> make[3]: *** [aphex_thread.lo] Error 1
>> make[3]: Leaving directory `/home/tonys/ferite/libs/aphex/src'
>> make[2]: *** [install-recursive] Error 1
>> make[2]: Leaving directory `/home/tonys/ferite/libs/aphex'
>> make[1]: *** [install-recursive] Error 1
>> make[1]: Leaving directory `/home/tonys/ferite/libs'
>> make: *** [install-recursive] Error 1
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can  
> you shotput
> a projector? How fast can you ride your desk chair down the office  
> luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> ferite-user mailing list
> fer...@li...
> https://lists.sourceforge.net/lists/listinfo/ferite-user
>