Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #106122 > unrolled thread

More problems with lcc-win

Back to article view | Back to comp.lang.c

Contents

  More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 00:29 -0700
    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 11:27 +0100
      Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 13:18 +0000
        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 15:22 +0100
          Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 08:26 -0700
      Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 08:25 -0700
        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 16:46 +0100
          Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-15 17:07 +0100
            Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 09:52 -0700
              Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 16:57 +0000
                Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 10:11 -0700
                  Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 18:17 +0000
              Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 17:21 +0000
                Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-15 18:42 +0100
                  Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-15 18:20 +0000
                    Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 18:59 +0000
                  Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-15 18:20 +0000
                    Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-15 19:39 +0100
                    Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 12:44 -0700
                      Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-15 20:19 +0000
                        Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 10:03 +0100
                          Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-16 11:15 +0000
                            Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-16 11:32 +0000
                            Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 13:41 +0100
                    Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-16 08:52 +0100
                    Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 09:57 +0100
                  Re: More problems with lcc-win antispam@math.uni.wroc.pl - 2017-03-16 13:53 +0000
                    Re: More problems with lcc-win jm.bourguet@gmail.com - 2017-03-16 07:14 -0700
                    Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-16 08:59 -0700
                Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 12:43 -0700
                  Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 20:39 +0000
              Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:56 +0100
          Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 16:33 +0000
            Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 17:47 +0100
              Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 10:04 -0700
                Re: More problems with lcc-win jacob navia <jacob@jacob.remcomp.fr> - 2017-03-16 00:52 +0100
                  Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 18:02 -0700
                    Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 18:23 -0700
                      Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-17 13:45 -0700
                        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:23 +0100
                          Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:29 +0100
                            Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:31 +0100
                            Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-17 17:01 -0700
                              Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-20 16:41 +0000
                                Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-20 18:32 +0100
                                  Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-20 18:18 +0000
                                    Re: More problems with lcc-win bart4858@gmail.com - 2017-03-20 12:31 -0700
                                      Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-20 21:05 +0100
                                        Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-20 20:45 +0000
                                      Re: More problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-20 20:18 +0000
                                      Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-21 09:56 +0100
                                        Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-21 21:08 +0000
                                          Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-21 22:19 +0100
                                            Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-22 06:29 +0000
                                          Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-21 16:12 -0700
                                            Re: More problems with lcc-win gordonb.s97bd@burditt.org (Gordon Burditt) - 2017-03-24 01:13 -0500
                                              Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-24 08:16 -0700
                                            Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-26 03:18 -0700
                                              Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-26 12:35 +0100
                                                Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-29 05:17 -0700
                                              Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-26 14:04 -0700
                                                Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-29 05:48 -0700
                                          Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-21 23:21 +0000
                                            Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-22 06:18 +0000
                                          Re: More problems with lcc-win gordonb.1neik@burditt.org (Gordon Burditt) - 2017-03-21 18:45 -0500
                                          Re: More problems with lcc-win jm.bourguet@gmail.com - 2017-03-22 01:02 -0700
                                          Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-22 10:35 +0100
                                          Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-22 13:21 +0000
                                            Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-22 14:08 +0000
                                              Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-22 15:37 +0000
                                          Re: More problems with lcc-win Gareth Owen <gwowen@gmail.com> - 2017-03-22 21:09 +0000
                                      Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-21 13:09 +0000
                                        Re: More problems with lcc-win Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-21 21:15 +0000
                          Re: More problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-18 12:44 +1300
                          Re: More problems with lcc-win jameskuyper@verizon.net - 2017-03-17 16:59 -0700
                        Re: charsets Noob <root@127.0.0.1> - 2017-03-18 18:30 +0100
                  Re: More problems with lcc-win David Brown <david.brown@hesbynett.no> - 2017-03-16 10:18 +0100
              Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 15:06 -0700
                Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 22:23 +0000
                  Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 15:43 -0700
                    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:53 +0100
                      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-16 08:35 -0700
                    Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 23:13 +0000
                      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-16 06:28 -0700
                        Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-16 16:56 +0000
                          Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-16 14:53 -0700
                Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 16:18 -0700
                  Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-16 18:03 +0000
                    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-16 19:29 +0100
                      Re: More problems with lcc-win Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-16 21:38 +0000
                      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-17 08:58 -0700
                  Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-17 09:45 -0700
                    Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-17 10:33 -0700
                      Re: More problems with lcc-win "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-17 14:20 -0400
                      Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-17 20:18 +0100
                        Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 00:44 -0700
                          Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-18 13:31 +0000
                            Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 15:54 -0700
                            Re: More problems with lcc-win scott@slp53.sl.home (Scott Lurndal) - 2017-03-20 13:27 +0000
                          Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-18 15:15 +0100
                            Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 11:39 -0700
                              Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-18 20:11 +0100
                                Re: More problems with lcc-win BartC <bc@freeuk.com> - 2017-03-18 19:45 +0000
                                  Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-20 00:35 -0700
                                Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 14:22 -0700
                                  Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-18 22:46 +0100
                                    Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-18 16:12 -0700
                                    Re: More problems with lcc-win supercat@casperkitty.com - 2017-03-18 18:01 -0700
                                      Re: More problems with lcc-win GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 03:21 +0100
                                        Re: More problems with lcc-win Ian Collins <ian-news@hotmail.com> - 2017-03-19 15:32 +1300
                                      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-19 02:17 -0700
      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:25 -0700
        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:49 +0100
    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 11:28 +0100
      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:35 -0700
        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:44 +0100
    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 13:06 +0100
      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:43 -0700
        Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 23:43 +0100
    Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 13:19 +0100
      Re: More problems with lcc-win mertesthomas@gmail.com - 2017-03-15 14:50 -0700
    Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 08:24 -0700
      Re: More problems with lcc-win jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-15 16:47 +0100
        Re: More problems with lcc-win jameskuyper@verizon.net - 2017-03-15 09:04 -0700
        Re: More problems with lcc-win Keith Thompson <kst-u@mib.org> - 2017-03-15 09:15 -0700
          Re: More problems with lcc-win gazelle@shell.xmission.com (Kenny McCormack) - 2017-03-15 19:59 +0000
        Re: More problems with lcc-win Richard Heathfield <rjh@cpax.org.uk> - 2017-03-15 16:32 +0000

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

#106445

Am Samstag, 18. März 2017 15:17:48 UTC+1 schrieb GOTHIER Nathan:
> On Sat, 18 Mar 2017 00:44:53 -0700 (PDT)
> mertesthomas wrote:
> 
> > For me this is where portability begins: The source code of a program
> > can be moved and it works without changing a single bit.
> 
> In the real world the portability begins where money flow... programmers don't
> live with only fresh water. ;-)

I don't get it.
When software can be moved without changing a single bit the 
effort to move the software is minimal. You just need to compile
the software at the new place. That's it.

Of cause programmers don't live with only fresh water.
Outside of hobby programming programmers need to be paid.

But when software is written in a portable language like Seed7
the actual porting is very cheap. There is no additional effort
needed to make a Seed7 program portable. It is automatically
source code portable.

Maybe you confused portability with porting. In that case your
statement makes more sense for me. E.g.:

  In the real world the porting begins where money flow...

Something like: Please port this Win32 C program to Linux.
If this program uses all tricks of Win32 moving it to Linux
can be harder than a complete rewrite. And this costs money...

> Actually the portability is a relative notion.
> 
> Source code need a specific compiler|interpreter which need a specific
> operating system.

Yes, but when I write a Seed7 program under Linux I can move the
source to Windows (without changing a single bit), compile it there
and send the .exe to somebody who can execute it under Windows.

For standard C this is also possible, but in standard C many things,
needed by practical programs, are just not available.

> Nothing is really 100 % portable,
[snip]

Agree, but it takes really some effort to create a non-portable
Seed7 program. I C this is just the other way around.

Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#106450

On Sat, 18 Mar 2017 11:39:28 -0700 (PDT)
mertesthomas@gmail.com wrote:

> I don't get it.
> When software can be moved without changing a single bit the 
> effort to move the software is minimal. You just need to compile
> the software at the new place. That's it.

If there is a compiler for that so-called portable language in other operating
systems. Thus the compiler isn't portable and has to be built from the
operating system parts (e.g. executable file format).


> Of cause programmers don't live with only fresh water.
> Outside of hobby programming programmers need to be paid.

That's why the free software and Linux failed. Major free software projects are
funded by software companies such as Microsoft or Red Hat.


> But when software is written in a portable language like Seed7
> the actual porting is very cheap. There is no additional effort
> needed to make a Seed7 program portable. It is automatically
> source code portable.

Still the compiler isn't portable. Replacing the hardware depedency with high
level portable languages only reduce the porting cost. If there is no compiler
for a so-called portable language there is no port-ability.


> Maybe you confused portability with porting. In that case your
> statement makes more sense for me. E.g.:
> 
>   In the real world the porting begins where money flow...

See above.

 
> Something like: Please port this Win32 C program to Linux.
> If this program uses all tricks of Win32 moving it to Linux
> can be harder than a complete rewrite. And this costs money...

Indeed.


> Yes, but when I write a Seed7 program under Linux I can move the
> source to Windows (without changing a single bit), compile it there
> and send the .exe to somebody who can execute it under Windows.

I noticed your compiler rely on third party libraries, consequently the
port-ability may be broken on some operating systems.

 
> For standard C this is also possible, but in standard C many things,
> needed by practical programs, are just not available.
> 
> > Nothing is really 100 % portable,
> [snip]
> 
> Agree, but it takes really some effort to create a non-portable
> Seed7 program. I C this is just the other way around.

[toc] | [prev] | [next] | [standalone]

#106451

On 18/03/2017 19:11, GOTHIER Nathan wrote:
> On Sat, 18 Mar 2017 11:39:28 -0700 (PDT)
> mertesthomas@gmail.com wrote:

>> But when software is written in a portable language like Seed7
>> the actual porting is very cheap. There is no additional effort
>> needed to make a Seed7 program portable. It is automatically
>> source code portable.
>
> Still the compiler isn't portable.

Which compiler? If building a program in a particular language can be 
reduced down to building from C, then C compilers are available just 
about everywhere.

(Last time I looked at Seed7, the main part was created in C, and could 
be supplied as a ready-to-go binary. Seed7 programs could either be 
interpreted, or compiled as C using a bundled C compiler.)

>> Something like: Please port this Win32 C program to Linux.
>> If this program uses all tricks of Win32 moving it to Linux
>> can be harder than a complete rewrite. And this costs money...
>
> Indeed.

It can be worse the other way. A program might not itself use all the 
tricks of Linux, but all the tools needed to build it do. Then striving 
to make such a program portable was a waste of time, if you get stuck at 
trying to run thousands of lines of 'bash' script.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#106533

Am Samstag, 18. März 2017 20:45:16 UTC+1 schrieb Bart:
> On 18/03/2017 19:11, GOTHIER Nathan wrote:
> > On Sat, 18 Mar 2017 11:39:28 -0700 (PDT)
> > mertesthomas wrote:
> 
> >> But when software is written in a portable language like Seed7
> >> the actual porting is very cheap. There is no additional effort
> >> needed to make a Seed7 program portable. It is automatically
> >> source code portable.
> >
> > Still the compiler isn't portable.
> 
> Which compiler? If building a program in a particular language can be 
> reduced down to building from C, then C compilers are available just 
> about everywhere.
> 
> (Last time I looked at Seed7, the main part was created in C, and could 
> be supplied as a ready-to-go binary. Seed7 programs could either be 
> interpreted, or compiled as C using a bundled C compiler.)
> 
> >> Something like: Please port this Win32 C program to Linux.
> >> If this program uses all tricks of Win32 moving it to Linux
> >> can be harder than a complete rewrite. And this costs money...
> >
> > Indeed.
> 
> It can be worse the other way. A program might not itself use all the 
> tricks of Linux, but all the tools needed to build it do. Then striving 
> to make such a program portable was a waste of time, if you get stuck at 
> trying to run thousands of lines of 'bash' script.

Trying to run a .BAT file with thousands of lines under Linux is a
similar effort. Because of the bad portability of scripts between
Linux and Windows I decided against a autoconf (and configure
scripts). Instead my configuration is based on C and make.

C and make are needed anyway to compile Seed7. So this does not add
an additional requirement. The work of the configure script is done
by the program chkccomp.c. Like a configure script chkccomp.c
creates tiny test programs and tries to compile and run them. The
results are written to the file version.h as #define macros.

A few settings are needed before chkccomp.c can be started:
- The path delimiter
- Details about the quoting needed for system()
- The name of the C compiler
- Compiler and linker options
- Does the compiler complain to stdout or stderr
- Extensions of object, library and executable files
- Libraries that must be linked

The settings needed by chkccomp.c are done in the makefile.
Basically every OS-compiler combination has its own makefile. This
is necessary, since C compilers often have their own make utility
with different behaviour. Especially the difference between nmake
(from Microsoft) and make (from any Unix like os) is significant.
To make things worse some makefiles need .BAT commands while others
execute bash commands. To reduce the complexity and size of the
makefiles I moved most of the settings to chkccomp.c. But there
are still some settings in the makefiles, that could be moved to
chkccomp.c.

Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#106454

Am Samstag, 18. März 2017 20:14:17 UTC+1 schrieb GOTHIER Nathan:
> On Sat, 18 Mar 2017 11:39:28 -0700 (PDT)
> mertesthomas wrote:
> 
> > I don't get it.
> > When software can be moved without changing a single bit the 
> > effort to move the software is minimal. You just need to compile
> > the software at the new place. That's it.
> 
> If there is a compiler for that so-called portable language in other operating
> systems. Thus the compiler isn't portable and has to be built from the
> operating system parts (e.g. executable file format).

We are talking about the portability of a program, not about
the portability of a compiler. Btw.: The Seed7 compiler is written
in Seed7 and therefore also source code portable.

> > Of cause programmers don't live with only fresh water.
> > Outside of hobby programming programmers need to be paid.
> 
> That's why the free software and Linux failed.

Do you want to start a Linux vs. Windows flame war?
Some things to consider:
Android is based on Linux and Android dominates the Smart-phone
marked. What about embedded computers? Washing machines,
Dishwashers, TV sets, Cars, etc. Newer-days almost all of them
contain computers and most this computers use Linux. This
embedded computers outnumber PCs by far. There are also many
internet servers running Linux and there are supercomputers
(the computers used for weather forecasting). Almost all
supercomputers use Linux. Linux is a big success, except
on the PC. Speaking of fail: MS Phone failed, although
Microsoft spent lots and lots of Money. Money is important
and I don't want to miss it, but it has its limits.

[snip]
> > But when software is written in a portable language like Seed7
> > the actual porting is very cheap. There is no additional effort
> > needed to make a Seed7 program portable. It is automatically
> > source code portable.
> 
> Still the compiler isn't portable. ...

As I said, we are talking about the source code portability of a
program: Source code (e.g. a Seed7 program) is moved to a computer
(that supports Seed7) and the program can be interpreted on this
computer or compiled to an executable of this computer. This is
for real. If you are not trolling you can download Seed7 and proof
it yourself.

[snip]
> I noticed your compiler rely on third party libraries, consequently the
> port-ability may be broken on some operating systems.

I did not say that Seed7 supports all operating systems.
The Seed7 run-time library needs to be operating system specific.
Between the supported operating systems (Linux, OS X (macOS),
FreeBSD, OpenBSD, Unix, Windows (XP, 7, 8, 10) Seed7 program
source code can be moved without change. Of cause Seed7 must be
installed on the destination computer. In this regard Seed7
is not different from Java. To execute a Java program a JVM
needs to be installed at the destination computer. The difference
is that Java is portable at the byte-code level, while Seed7
is portable at the source level. In comparison to that C programs
are usually not portable at all (they need to be changed to
fit to a different os).

Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#106455

On Sat, 18 Mar 2017 14:22:33 -0700 (PDT)
mertesthomas@gmail.com wrote:


> I did not say that Seed7 supports all operating systems.
> The Seed7 run-time library needs to be operating system specific.
> Between the supported operating systems (Linux, OS X (macOS),
> FreeBSD, OpenBSD, Unix, Windows (XP, 7, 8, 10) Seed7 program
> source code can be moved without change. Of cause Seed7 must be
> installed on the destination computer. In this regard Seed7
> is not different from Java. To execute a Java program a JVM
> needs to be installed at the destination computer. The difference
> is that Java is portable at the byte-code level, while Seed7
> is portable at the source level. In comparison to that C programs
> are usually not portable at all (they need to be changed to
> fit to a different os).

The port-ability depends on the availability of a compiler or an
interpreter, nothing less nothing more.

Your C bashing in a desperate attempt to promote your Seed7 language is
ridiculous...

[toc] | [prev] | [next] | [standalone]

#106457

Am Samstag, 18. März 2017 22:48:35 UTC+1 schrieb GOTHIER Nathan:
> On Sat, 18 Mar 2017 14:22:33 -0700 (PDT)
> mertesthomas wrote:
> 
> 
> > I did not say that Seed7 supports all operating systems.
> > The Seed7 run-time library needs to be operating system specific.
> > Between the supported operating systems (Linux, OS X (macOS),
> > FreeBSD, OpenBSD, Unix, Windows (XP, 7, 8, 10) Seed7 program
> > source code can be moved without change. Of cause Seed7 must be
> > installed on the destination computer. In this regard Seed7
> > is not different from Java. To execute a Java program a JVM
> > needs to be installed at the destination computer. The difference
> > is that Java is portable at the byte-code level, while Seed7
> > is portable at the source level. In comparison to that C programs
> > are usually not portable at all (they need to be changed to
> > fit to a different os).
> 
> The port-ability depends on the availability of a compiler or an
> interpreter, nothing less nothing more.
> 
> Your C bashing in a desperate attempt to promote your Seed7 language is
> ridiculous...

You misinterpret my argumentation about C.
I lived from programming C for many years. Later it was C++ and
for some years now I live from programming Java. The Seed7
interpreter and the system dependent parts of the Seed7 run-time
library are written in C. I am just criticizing the portability
of C. Nothing more, nothing less. Criticizing is not bashing.
I don't do C bashing.


Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#106461

On Saturday, March 18, 2017 at 4:48:35 PM UTC-5, GOTHIER Nathan wrote:
>                                In comparison to that C programs
> > are usually not portable at all (they need to be changed to
> > fit to a different os).
> 
> The port-ability depends on the availability of a compiler or an
> interpreter, nothing less nothing more.
> 
> Your C bashing in a desperate attempt to promote your Seed7 language is
> ridiculous...

A language that promises certain features will only be usable on systems that
have such features, but will allow programs that require those features to be
run without modification on all systems that support them.

If a language offers optional features, then programs that require those
features will only be usable on systems that support then, but the language
will be usable on systems that can't support those features, for the purpose
of running programs that don't require them.

There are many features which are supported by many systems upon which C
is run, and which many programs require, but which the C Standard does not
acknowledge in any way whatsoever.  Some of these features are available,
wit consistent syntax, on most compilers for commonplace platforms, though
they may require suitable configuration of compiler options.  Others are
supported different ways on different systems and require different code
to handle them.

I'm not familiar with seed7 myself, but perhaps Thomas Mertes would like
to offer up a program that reads one key from the console, without echo
or buffering, and then returns its ASCII code.  In a C compiler for MS-DOS
such a program would be:

    #include <conio.h>
    int main(void) { return getch(); }

but such a program would not be portable to very many other systems.  From
what I've read here, however, I would expect a seed7 equivalent would be
portable to all systems that support seed7, which would be a much larger
set.  Perhaps people who think C is more portable than seed7 would like to
suggest how the above simple program might be written in portable C?  Or
maybe they don't think any program that would need such an ability should be
considered "portable".

[toc] | [prev] | [next] | [standalone]

#106462

On Sat, 18 Mar 2017 18:01:15 -0700 (PDT)
supercat@casperkitty.com wrote:

> I'm not familiar with seed7 myself, but perhaps Thomas Mertes would like
> to offer up a program that reads one key from the console, without echo
> or buffering, and then returns its ASCII code.  In a C compiler for MS-DOS
> such a program would be:
> 
>     #include <conio.h>
>     int main(void) { return getch(); }
> 
> but such a program would not be portable to very many other systems.  From
> what I've read here, however, I would expect a seed7 equivalent would be
> portable to all systems that support seed7, which would be a much larger
> set.  Perhaps people who think C is more portable than seed7 would like to
> suggest how the above simple program might be written in portable C?  Or
> maybe they don't think any program that would need such an ability should be
> considered "portable".

Maybe you should consider reading K&R or the ISO 9899 standard to find out
that the <conio.h> header doesn't belong to the standard C library. Any
portable C code only rely on the C language and its standard library because
that's the only environment secured by the language.

[toc] | [prev] | [next] | [standalone]

#106463

On 03/19/17 03:21 PM, GOTHIER Nathan wrote:
> On Sat, 18 Mar 2017 18:01:15 -0700 (PDT)
> supercat@casperkitty.com wrote:
>
>> I'm not familiar with seed7 myself, but perhaps Thomas Mertes would like
>> to offer up a program that reads one key from the console, without echo
>> or buffering, and then returns its ASCII code.  In a C compiler for MS-DOS
>> such a program would be:
>>
>>      #include <conio.h>
>>      int main(void) { return getch(); }
>>
>> but such a program would not be portable to very many other systems.  From
>> what I've read here, however, I would expect a seed7 equivalent would be
>> portable to all systems that support seed7, which would be a much larger
>> set.  Perhaps people who think C is more portable than seed7 would like to
>> suggest how the above simple program might be written in portable C?  Or
>> maybe they don't think any program that would need such an ability should be
>> considered "portable".
>
> Maybe you should consider reading K&R or the ISO 9899 standard to find out
> that the <conio.h> header doesn't belong to the standard C library.

That's what he said...

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#106470

Am Sonntag, 19. März 2017 02:01:22 UTC+1 schrieb supe...@casperkitty.com:
> On Saturday, March 18, 2017 at 4:48:35 PM UTC-5, GOTHIER Nathan wrote:
> >                                In comparison to that C programs
> > > are usually not portable at all (they need to be changed to
> > > fit to a different os).
> > 
> > The port-ability depends on the availability of a compiler or an
> > interpreter, nothing less nothing more.
> > 
> > Your C bashing in a desperate attempt to promote your Seed7 language is
> > ridiculous...
> 
> A language that promises certain features will only be usable on systems that
> have such features, but will allow programs that require those features to be
> run without modification on all systems that support them.
> 
> If a language offers optional features, then programs that require those
> features will only be usable on systems that support then, but the language
> will be usable on systems that can't support those features, for the purpose
> of running programs that don't require them.
> 
> There are many features which are supported by many systems upon which C
> is run, and which many programs require, but which the C Standard does not
> acknowledge in any way whatsoever.  Some of these features are available,
> wit consistent syntax, on most compilers for commonplace platforms, though
> they may require suitable configuration of compiler options.  Others are
> supported different ways on different systems and require different code
> to handle them.
> 
> I'm not familiar with seed7 myself, but perhaps Thomas Mertes would like
> to offer up a program that reads one key from the console, without echo
> or buffering, and then returns its ASCII code.  In a C compiler for MS-DOS
> such a program would be:
> 
>     #include <conio.h>
>     int main(void) { return getch(); }

The Seed7 equivalent would be:

    $ include "seed7_05.s7i";
      include "keybd.s7i";

    const proc: main is func
      begin
        exit(ord(getc(KEYBOARD)));
      end func;

The handling of a return value from main is operating system
dependent. E.g.: It needs operating system dependent handling to
make the return value from main visible at the command line.
Therefore I would prefer a program that writes the ASCII code:

    $ include "seed7_05.s7i";
      include "keybd.s7i";

    const proc: main is func
      begin
        writeln(ord(getc(KEYBOARD)));
      end func;

This program behaves the same on Linux, OS X, FreeBSD, OpenBSD and
Windows. Even when you press function or cursor keys you get the
same result.

The Seed7 release contains a program named kbd.sd7, which shows
key-code and description of the keys pressed. Naturally key-code and
description are the same at all supported operating systems. There
is also a program named gkbd.sd7, which does the same while it
displays a window with a moving dot. This program reads also from
the file KEYBOARD and delivers the same results on all supported
operating systems as the console program kbd.sd7. Under the hood
graphic and console programs use different driver libraries to read
a key. So the driver libraries do not only differ between operating
systems, but also between console and graphic programs.

Reading single key presses without echo is just a small part of
the effort to reach portability. For other areas (doing graphics,
reading directory contents, starting processes, database access,
network access, etc.) there are also driver libraries.

[snip]
> ....  From
> what I've read here, however, I would expect a seed7 equivalent would be
> portable to all systems that support seed7, which would be a much larger
> set.  Perhaps people who think C is more portable than seed7 would like to
> suggest how the above simple program might be written in portable C?  Or
> maybe they don't think any program that would need such an ability should be
> considered "portable".

The Fox and the Grapes...


Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [next] | [standalone]

#106178

Am Mittwoch, 15. März 2017 11:28:06 UTC+1 schrieb jacobnavia:
> Le 15/03/2017 à 08:29, mertesthomas a écrit :
> >    For 64 bit compile with: lc64 -A testlcc_4.c
> >    (the compiler complains about: missing prototype for fseeki64
> >    so fseeki64 seems to be missing in the header stdio.h) and run
> >    the program. With version 4.1 of lcc-win (64 bits) it writes:
> >  ***** Error: S_ISREG is not defined in <sys/stat.h>
> >  ***** Error: S_IFMT is not defined in <sys/stat.h>
> >  ***** Error: ENOTDIR is not defined in <errno.h>
> >  ***** Error: ENAMETOOLONG is not defined in <errno.h>
> >  ***** Error: EXDEV is not defined in <errno.h>
> > 1 <= 308 is TRUE
> >  ***** Error: The S_IFREG bit of a regular file is not set.
> > -----------------------------------------------------------
> >    Afterwards the 64-bit program crashes because fseeki64() is
> >    missing in the run-time library.
> 
> As I told you before, fseeki64 doesn't exist in the 64 bit version and 
> has been replaced by fseek now, that returns a long long

As others have pointed out the 2nd parameter of your fseek has
the type long long.

> You should also notice that you are under windows, ...

Can we agree that Microsoft defines the interfaces of windows.
According to MSDN the prototype of the windows function fseek is:

  int fseek(FILE *stream, long offset, int origin);

the 64-bit version of fseek is defined by Microsoft as:

  int _fseeki64(FILE *stream, __int64 offset, int origin);

Before Microsoft introduced the _ the function was called fseeki64.

> ... that doesn't 
> implement any of the POSIX bits you are trying to use. Since lcc-win is 
> not posix under windows, those things are not implemented.

Your fseek function is neither windows nor POSIX.

> The st!mode member of the stats structure contains the file attributes 
> as WINDOWS sets them.

Your implementation of stat is the only one that uses the file attributes
of windows for st_mode. The runtime of all other C compilers uses POSIX
like bits for the st_mode field of the stat structure. Not only gcc
(MinGW and Cygwin), clang and tcc, but also Visual C, Borland C and
Pelles C. Even your 32-bit version of lcc-bin does use POSIX like bits
for the st_mode field of the stat structure.

So again you decide for something that nobody else uses.

Btw.: Your definition of S_IFREG as 0x0100000 looks strange.
The program testlcc_4.c shows that for a regular file the S_IFREG
bit of the st_mode file is not set.

So you are not only incompatible to everyone else your also
did it wrong. The definition of the macro S_ISREG is missing.
The header sys/stat.h of every other C compiler defines
the macro S_ISREG, but you just omit it. The most usual use case
of the stat function IS the check if a file is a regular file.
This use case is just not possible.

> You could also add some defines to the stat.h file to make a translation.

I found a way to avoid your stat() function in the 64-bit version totally.

> Of course I could do the modifications for you, ...

You think you do me a favour, when you fix such severe problems?
You want to sell lcc-win, so you should do the modifications to
improve your business opportunities.

... or you could buy a 
> source license and fix everything you do not like.

Thank you for your offer.
Normally someone buys something that is already fixed.
Usually things are not bought, such that the customer can fix it.

I spent a lot of hours to create the lcc-win test programs and
I thought they could be useful for you.


Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows. 

[toc] | [prev] | [next] | [standalone]

#106198

Le 15/03/2017 à 22:25, mertesthomas@gmail.com a écrit :
> So you are not only incompatible to everyone else your also
> did it wrong.

Yes. That's true. Maybe because I do not fit anywhere, I am a french and 
whatever. Or because I was fed up and did not think a lot about it, or 
because my kids came into my office and I left the thing in the middle 
and when I came back it was late and I wanted to finish that stuff quickly.

Who knows why?

I don't. In any case its maybe wrong and some bits somewhere are badly 
written.

So is life Thomas. Stuff happens.

[toc] | [prev] | [next] | [standalone]

#106125

Le 15/03/2017 à 08:29, mertesthomas@gmail.com a écrit :
> /* Compile with: lc64 -c -g5 testlcc_5.c */

Do not use the -g5 option with lcc64. It will not work, I haven't done 
that in 64 bits.

[toc] | [prev] | [next] | [standalone]

#106179

Am Mittwoch, 15. März 2017 11:28:51 UTC+1 schrieb jacobnavia:
> Le 15/03/2017 à 08:29, mertesthomas a écrit :
> > /* Compile with: lc64 -c -g5 testlcc_5.c */
> 
> Do not use the -g5 option with lcc64. It will not work, I haven't done 
> that in 64 bits.

I get the same error also with -g4 and -g3.


Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows. 

[toc] | [prev] | [next] | [standalone]

#106195

Le 15/03/2017 à 22:35, mertesthomas@gmail.com a écrit :
> I get the same error also with -g4 and -g3.

Use only g2. Actually I will change that to -g without any steps.

[toc] | [prev] | [next] | [standalone]

#106128

Le 15/03/2017 à 08:29, mertesthomas@gmail.com a écrit :
> - Lc requires that the linker options are at the end. Other
>   compilers use options like: -Wl,linker-option to specify linker
>   options. My handling of linker options does not work with the
>   "linker options must be last" concept.

Yes, that could be a problem. If you buy a source license you can modify 
lc/lc64 as you need.

[toc] | [prev] | [next] | [standalone]

#106180

Am Mittwoch, 15. März 2017 13:06:07 UTC+1 schrieb jacobnavia:
> Le 15/03/2017 à 08:29, mertesthomas a écrit :
> > - Lc requires that the linker options are at the end. Other
> >   compilers use options like: -Wl,linker-option to specify linker
> >   options. My handling of linker options does not work with the
> >   "linker options must be last" concept.
> 
> Yes, that could be a problem. If you buy a source license you can modify 
> lc/lc64 as you need.

Thank you for the offer. I like to help you to improve lc/lc64,
but I do not plan to buy a license of lcc-win.

Does this business model (selling to somebody that needs modifications)
work?


Regards,
Thomas Mertes

-- 
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows. 

[toc] | [prev] | [next] | [standalone]

#106194

Le 15/03/2017 à 22:43, mertesthomas@gmail.com a écrit :
>
> Thank you for the offer. I like to help you to improve lc/lc64,
> but I do not plan to buy a license of lcc-win.
>
> Does this business model (selling to somebody that needs modifications)
> work?
>

I have been able to pay the bills. By the way, it is not the model that 
is working. Models do not work. It's me that works

:-)

Basically you ask me to do something for you: a small improvement, 
whatever. Maybe I do it, maybe not, I can't take any work more than what 
I do have already to do, so I can't do that at this moment.

Since I am lucky, you did not buy any maintenance license, so I do not 
have any formal engagement for you.

jacob

[toc] | [prev] | [next] | [standalone]

#106129

Le 15/03/2017 à 08:29, mertesthomas@gmail.com a écrit :
> - The header stdio.h does not contain the prototype of wfopen().

Fixed. Will be in next release

> - The header errno.h is missing definitions of ENOTDIR and
>   ENAMETOOLONG.

Yes, many definitions are missing from POSIX. May I remind you that the 
standard just mandates 3 errors?

EDOM
EILSEQ
ERANGE

All other macros are not standard

> - The header conio.h is missing.

Obviously, we aren't in DOS anymore...
Use the console functions from Microsoft that developed a new API.

> - In include64/sys/stat.h the definition of S_ISCHR uses _S_IFCHR
>   instead of S_IFCHR.

Fixed, will be in next release

> - The function _pclose is missing in the 64-bit run-time library.

Yes, since you should use CloseHandle to close a pipe.

> - The function _wsystem is missing in both the 32-bit and 64-bit
>   run-time library.

That function is not mentioned in the C standard (99 edition), but I 
will add it in the future. If you wish I can send you the code of the 
system() function and you can modify it for wide chars. It is not very 
difficult.

[toc] | [prev] | [next] | [standalone]

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web