On Sat, 2014-01-11 at 04:08 +0100, tging...@free.fr wrote:
Hi !
Le 2014-01-10 21:08, Brian Drummond a écrit :
Another user routinely links to C code (and I have linked to Ada)
using
the VHPI interface; as the mcode compiler supports neither of these
languages, the gcc version is
On Sat, 2014-01-11 at 04:08 +0100, tging...@free.fr wrote:
See ghdlrun.adb: Foreign_Hook. This function is called for each
foreign
subprogram, and return the address of the foreign routine. That's
where
dlopen/dlsym should be added.
Would this work with any external .DLL (.SO)
Le 2014-01-11 13:18, Martin Strubel a écrit :
Hi Brian and all,
Hi !
Sorry for drifting off a little, maybe we should open another thread on
the VHPI topic?
definitely :-)
Greetings,
- Martin
YG
___
Ghdl-discuss mailing list
On Fri, 10 Jan 2014 20:08:57 +
Brian Drummond br...@shapes.demon.co.uk wrote:
Generally no, neither is preferred; they serve different purposes
and
each has its strengths.
One recent user found the gcc version choked with huge
auto-generated
VHDL source files (along the
On Thu, 2014-01-09 at 22:27 -0500, Adam Jensen wrote:
On Fri, 10 Jan 2014 03:58:06 +0100 (CET)
tging...@free.fr wrote:
For FreeBSD, I'd like to see this issue fixed, but I don't really know
how to help.
I will start tinkering with the test-suite this evening. I've been
thinking about
On Fri, 10 Jan 2014 10:54:27 +
Brian Drummond br...@shapes.demon.co.uk wrote:
tagging it; expect to see a ghdl-0.31_release tag (or other wording
if anyone can improve on it)
Consistency throughout might be nice. For example:
version.ads contains:
- Ghdl_Ver : constant String := 0.31;
On Fri, 10 Jan 2014 12:12:52 +
Brian Drummond br...@shapes.demon.co.uk wrote:
I also have an effort under way on this (which was superseded by some
of Tristan's commits last week) but think I have observed the same
failure (gcc build, Linux : Debian Jessie).
yes:
Test: 375
ghdl -a
[...]
What you can do is freeze a release point within that branch by
tagging
it; expect to see a ghdl-0.31_release tag (or other wording if
anyone
can improve on it) in the next day or so.
For the next release, I propose to name the branch 'branch-0.32'
and releases 'ghdl-0.32',
On Fri, 10 Jan 2014 18:49:48 +0100 (CET)
tging...@free.fr wrote:
Yes, I am finally done. I have tested ghdl_mcode with the
different
testsuites.
Is the mcode variant preferred over the gcc variant?
Not really. They are two different trade-offs.
Mcode is very small and very
On Fri, 2014-01-10 at 13:38 -0500, Adam Jensen wrote:
Is the mcode variant preferred over the gcc variant? What's the most
likely cause of ghdl-gcc failing tests while ghdl-mcode passes the
tests?
Generally no, neither is preferred; they serve different purposes and
each has its strengths.
Hi !
Le 2014-01-10 21:08, Brian Drummond a écrit :
Another user routinely links to C code (and I have linked to Ada) using
the VHPI interface; as the mcode compiler supports neither of these
languages, the gcc version is essential to him.
According to Tristan, support of external dynamic
Hi !
Le 2014-01-10 21:08, Brian Drummond a écrit :
Another user routinely links to C code (and I have linked to Ada)
using
the VHPI interface; as the mcode compiler supports neither of these
languages, the gcc version is essential to him.
According to Tristan, support of external
On Thu, 9 Jan 2014 08:57:44 +0100 (CET)
tging...@free.fr wrote:
mcode is the integrated code generator, which can be used instead
of the gcc backend. It is way faster and smaller, but generated
code is worse than gcc -O.
Does mcode generate bytecode for a virtual machine (managed runtime
On Thu, 2014-01-09 at 03:12 -0500, Adam Jensen wrote:
On Thu, 9 Jan 2014 08:57:44 +0100 (CET)
tging...@free.fr wrote:
mcode is the integrated code generator, which can be used instead
of the gcc backend. It is way faster and smaller, but generated
code is worse than gcc -O.
Does
On Thu, 9 Jan 2014 08:57:44 +0100 (CET)
tging...@free.fr wrote:
mcode is the integrated code generator, which can be used instead
of the gcc backend. It is way faster and smaller, but generated
code is worse than gcc -O.
Does mcode generate bytecode for a virtual machine (managed
David Koontz wrote:
the ghdl-0.29-1 download link on ghdl.free.fr pointed
to ghdl-0.29 until I patched the link about a year ago.
In the mean time we had Windows users swearing
ghdl was broken.
The outdated links[1] were confusing.
But note that both the 0.29 and the 0.29.1 Windows builds
I'm not sure I even understand your general sentiment now. No worries,
someone else can sort it out. There are plenty of other interesting
things to work on.
signature.asc
Description: PGP signature
___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
My fault. A lack of communication and synchronisation. I thought
we were still in release candidate mode. I committed some changes
in the release branch, mostly to doc files, and also to fix a
regression. Now that the test suites are clean for me, I don't plan
to commit anything else.
Here is
I think I empathize with your general sentiment but I'm not sure I
understand your proposal.
On Fri, 10 Jan 2014 09:58:05 +1300
David Koontz diogra...@gmail.com wrote:
The idea of a release is to make a version of the code that doesn't
change. It represents a snapshot in development.
On 10 Jan 2014, at 12:14 pm, Adam Jensen han...@riseup.net wrote:
I think I empathize with your general sentiment but I'm not sure I
understand your proposal.
On Fri, 10 Jan 2014 09:58:05 +1300
David Koontz diogra...@gmail.com wrote:
The idea of a release is to make a version of
On Fri, 10 Jan 2014 03:58:06 +0100 (CET)
tging...@free.fr wrote:
For FreeBSD, I'd like to see this issue fixed, but I don't really know
how to help.
I will start tinkering with the test-suite this evening. I've been
thinking about writing a testing driver script that will launch
[parallel][1]
On Fri, 10 Jan 2014 03:58:06 +0100 (CET)
tging...@free.fr wrote:
For FreeBSD, I'd like to see this issue fixed, but I don't really
know
how to help.
I will start tinkering with the test-suite this evening. I've been
thinking about writing a testing driver script that will launch
On Wed, 08 Jan 2014 06:33:39 +0100
why...@f-cpu.org wrote:
from a user point of view, I just need a GHDL that works...
Groovy. A working GHDL is probably the general consensus.
Sure. I think we don't really have the resources to maintain 2 or 3 branches.
I far prefer to have the
It wouldn't hurt to have a wiki page on how to do -2008 features in
ghdl.
Something like:
http://sourceforge.net/p/ghdl-updates/wiki/RoadMap2008/
??? :-)
___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
On 8 Jan 2014, at 9:34 pm, tging...@free.fr wrote:
It wouldn't hurt to have a wiki page on how to do -2008 features in
ghdl.
Something like:
http://sourceforge.net/p/ghdl-updates/wiki/RoadMap2008/
No something that actually tells how to get the 2008 libraries into a useable
state.
On Wed, 2014-01-08 at 04:47 +0100, tging...@free.fr wrote:
I backported the copyright dates, as an exercise. Then I made a
commit
to the default branch to keep tip attached to default, reducing
the
chance that a commit will happen to 0.31 by mistake...
Hope it looks OK as an
On Wed, 2014-01-08 at 13:03 +1300, David Koontz wrote:
On 8 Jan 2014, at 12:33 pm, Brian Drummond br...@shapes.demon.co.uk wrote:
At last I think I have it...
There are now two branches; ghdl-0.31 and default.
Hope it looks OK as an 0.31 release...
I'll make a source download
On Tue, 2014-01-07 at 23:55 -0500, Adam Jensen wrote:
On Wed, 8 Jan 2014 03:41:37 +0100 (CET)
tging...@free.fr wrote:
On Tue, 07 Jan 2014 23:33:52 +
Brian Drummond br...@shapes.demon.co.uk wrote:
There are now two branches; ghdl-0.31 and default.
I'm not sure whether
On Wed, 2014-01-08 at 04:47 +0100, tging...@free.fr wrote:
I backported the copyright dates, as an exercise. Then I made a
commit
to the default branch to keep tip attached to default,
reducing
the
chance that a commit will happen to 0.31 by mistake...
Hope it looks
On Wed, 2014-01-08 at 05:09 -0500, Adam Jensen wrote:
On Wed, 8 Jan 2014 09:26:50 +0100 (CET)
tging...@free.fr wrote:
I think we don't really have the resources to maintain 2 or 3
branches.
I suspect we need two : release and current. More than that ... I would
agree...
Hmm, can either of
* -RC : when -stable is internally consistent, rigorous testing and
polishing can begin on a Release Candidate snapshot.
Clearly that would be an improvement over the last day or two :-)
Sorry
about that, folks... probably RC1 - release will suffice for ghdl.
Maybe we should re-add
On Wed, 08 Jan 2014 21:06:45 +
Brian Drummond br...@shapes.demon.co.uk wrote:
The usual Mercurial approach to big picture changes is to clone the
entire repo (see www.hginit.com, last chapter) essentially forking the
project for the separate development. It's safer (there is no danger
op
On Wed, 08 Jan 2014 21:06:45 +
Brian Drummond br...@shapes.demon.co.uk wrote:
I suspect we need two : release and current. More than that ... I
would agree...
How about this as a two-branch naming convention? (Old release branches
can be retired). Remember, a naming convention is only
Hello,
* -RC : when -stable is internally consistent, rigorous testing
and
polishing can begin on a Release Candidate snapshot.
Clearly that would be an improvement over the last day or two :-)
Sorry
about that, folks... probably RC1 - release will suffice for ghdl.
Maybe
On Thu, 9 Jan 2014 07:08:44 +0100 (CET)
tging...@free.fr wrote:
So for me (using mcode), ghdl-0.31 is good.
I don't know what mcode represents in this context (obviously not
MATLAB scripts). Have you stopped testing and supporting the gcc
version?
signature.asc
Description: PGP signature
On Tue, 2014-01-07 at 06:38 +0100, tging...@free.fr wrote:
On Mon, 2014-01-06 at 22:21 +0100, Joris van Rantwijk wrote:
On 2014-01-05, tging...@free.fr wrote:
I think we are ready for a new release.
...
I'm looking forward to the release. Clearly a lot of bugs have been
fixed and
On 8 Jan 2014, at 12:33 pm, Brian Drummond br...@shapes.demon.co.uk wrote:
At last I think I have it...
There are now two branches; ghdl-0.31 and default.
After cloning the repo (hg clone) or pulling changes to an existing one,
hg update ghdl-0.31
will select the stable 0.31 branch,
Great!
- Mail original -
On Tue, 2014-01-07 at 06:38 +0100, tging...@free.fr wrote:
On Mon, 2014-01-06 at 22:21 +0100, Joris van Rantwijk wrote:
On 2014-01-05, tging...@free.fr wrote:
I think we are ready for a new release.
...
I'm looking forward to the release. Clearly
On Tue, 07 Jan 2014 23:33:52 +
Brian Drummond br...@shapes.demon.co.uk wrote:
On Tue, 2014-01-07 at 06:38 +0100, tging...@free.fr wrote:
I have also added the tag 0.31rc1 (Tristan, should I just
re-tag
as 0.31?)
(I would have created a branch-0.31, and tag there)
I backported the copyright dates, as an exercise. Then I made a
commit
to the default branch to keep tip attached to default, reducing
the
chance that a commit will happen to 0.31 by mistake...
Hope it looks OK as an 0.31 release...
I'll make a source download package tomorrow if I
On Wed, 8 Jan 2014 03:41:37 +0100 (CET)
tging...@free.fr wrote:
On Tue, 07 Jan 2014 23:33:52 +
Brian Drummond br...@shapes.demon.co.uk wrote:
On Tue, 2014-01-07 at 06:38 +0100, tging...@free.fr wrote:
I have also added the tag 0.31rc1 (Tristan, should I just
re-tag
as
Le 2014-01-08 05:55, Adam Jensen a écrit :
This might be insanely over-elaborate
It is :-D
from a user point of view, I just need a GHDL that works...
Ideally, one that Tristan endorses.
yg
___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
On Wed, 08 Jan 2014 06:33:39 +0100
why...@f-cpu.org wrote:
from a user point of view, I just need a GHDL that works...
Groovy. A working GHDL is probably the general consensus.
Ideally, one that Tristan endorses.
Okay. I imagine every release must be sanctioned by [at least one of]
the
On 8 Jan 2014, at 1:03 pm, David Koontz diogra...@gmail.com wrote:
On 8 Jan 2014, at 12:33 pm, Brian Drummond br...@shapes.demon.co.uk wrote:
At last I think I have it...
There are now two branches; ghdl-0.31 and default.
After cloning the repo (hg clone) or pulling changes to an
On Mon, 2014-01-06 at 23:15 +0900, D. Jeff Dionne wrote:
We use GHDL for simulation of (digital blocks of) mixed signal chips and a
large
SoC under development. We can test once there is a tagged release candidate.
I'm not sure if this has been found and corrected or not: function mod
Thanks Brian,
Just for clarity, it was only mod that was a problem from math_real,
so it seems (a reimplementation of?) ieee.math_real is present. This
is 0.29.
Cheers, thanks again,
J.
The problem was the licensing terms of the IEEE math libraries; these
terms have been relaxed and they are
On 2014-01-05, tging...@free.fr wrote:
I think we are ready for a new release.
I did a quick testrun with today's snapshot to see if I can still build
a Debian package. It looks good. The build runs almost without problems.
The resulting compiler works well on my favorite VHDL project.
I ran
On Mon, 2014-01-06 at 22:21 +0100, Joris van Rantwijk wrote:
On 2014-01-05, tging...@free.fr wrote:
I think we are ready for a new release.
I did a quick testrun with today's snapshot to see if I can still build
a Debian package. It looks good. The build runs almost without problems.
The
On 7 Jan 2014, at 11:13 am, Brian Drummond br...@shapes.demon.co.uk wrote:
I have also added the tag 0.31rc1 (Tristan, should I just re-tag as
0.31?)
As soon as you do I'll build an OS X version.
___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
On Mon, 2014-01-06 at 22:21 +0100, Joris van Rantwijk wrote:
On 2014-01-05, tging...@free.fr wrote:
I think we are ready for a new release.
I did a quick testrun with today's snapshot to see if I can still
build
a Debian package. It looks good. The build runs almost without
Hello,
I think we are ready for a new release.
First, I'd like to know if someone wants to volunteer for
the whole release process. Please, speak up!
The current (well, the old one) release plan is contained in
translate/gcc/dist.sh It must be slightly updated at least
for the use of
On Sun, 2014-01-05 at 20:19 +0100, tging...@free.fr wrote:
Hello,
I think we are ready for a new release.
Excellent! And thank you for putting so much into it over the last
couple of weeks!
First, I'd like to know if someone wants to volunteer for
the whole release process. Please, speak
On Sun, 5 Jan 2014 20:19:15 +0100 (CET)
tging...@free.fr wrote:
I think we are ready for a new release.
Excellent timing. I re-tasked one of my machines to be a test box for
the various ghdl on FreeBSD build methods so they can be verified on a
freshly installed system. I will keep [build
On Mon, 2014-01-06 at 11:20 +1300, David Koontz wrote:
On 6 Jan 2014, at 10:18 am, Brian Drummond br...@shapes.demon.co.uk wrote:
There are too many combinations of OS, distribution, platform to cover
all the bases with binary releases! Debian etc would prefer to work from
a source
Thank you everybody for your efforts !
concerning binary distributions,
i'm interested because i'm totally confused about the build process
and have an outdated distro too so... please make a linux x86 package
:-)
Happy new year and congrats for the new milestone !
55 matches
Mail list logo
