dmgolubovsky / yhc Goto Github PK

What steps will reproduce the problem?
1. Build Yhc
2. Cd test/WheelSeive2
3. yhc Main.hs
4. yhi Main.hbc

What is the expected output? What do you see instead?

The expected output is not a crash.

Below is the gdb output for the crash.

0x08052dd7 in mark_CAFs () at src/runtime/BCKernel/mark.c:337
337           if (finfo->constTypes[i] == C_NODE){
(gdb) print finfo
$1 = (FInfo *) 0x80d8d28
(gdb) print finfo->constTypes
$2 = (UByte *) 0x0
(gdb)  

Currently our haddock documentation is just the normal stuff.

See:
http://www-users.cs.york.ac.uk/~ndm/projects/filepath/System-FilePath.html

This has cool source code links plus coloured source code. This requires
HEAD builds of HsColour and Haddock (both of which are on the windows docs
machine).

See http://www.cs.york.ac.uk/fp/darcs/filepath/make-docs.bat for some of
the logic to do this.

There are now some scons flags (core=1, arch=X86) that often want setting
for all builds, even when you forget. Possibly have a text file that scons
reads for these options or something?

Yhc used to have haddock documentation at:
http://www-users.cs.york.ac.uk/~ndm/yhc/docs/

Now that page is outdated, ages ago. Perhaps there could be a new scons
build docs target which makes the documentation in inst\docs, and the
snapshot machine could copy it onto the web somewhere.

The test about packed strings fails on OS X PPC, no particular idea why.

The first step is to insert traces around each function, so we can figure
out precisely which item fails.

Note that its useful to track down why, but Data.ByteString is clearly the
future :)

I want to examine yhc bytecode, but Robert Dockins's library
(http://www.eecs.tufts.edu/~rdocki01/yhc-bytecode.html) complains of a
"Bad version"

-- Kartik Vaddadi

Yhc uses a lot of magic, esp for things like integer addition etc.

These should be replaced with primitives, the magic'ness should be deleted
from the compiler, and then the back end show recognise these primtives as
bytecodes.

Magic is bad.

Scons build library has prebaked notions of dependancy, which are't quite
right. It should use Yhc's dependancy analyser to do this, or Yhc's make
mode (if possible).

Probably depends on bug 6, Yhc.Make library, and then exposing that
information through command line flags.

I've been trying to debug the mac ppc, which fails with:
src/runtime/BCKernel/thread.c:126: failed assertion `rval==0'

The reason is that sem_init returns -1, to indicate error, and an
error number that indicates ENOSYS: The function sem_init() is not
supported by this implementation.

See http://www.opengroup.org/onlinepubs/007908799/xsh/sem_init.html
for more details.

From http://unu.novajo.ca/simple/

Specific comments and pitfalls:

  1. The thread function sem_init is not implemented on Darwin
whereas the functions sem_open/sem_close is not implemented on Linux.
That's why there is some juggling with the initialization of the
semaphores in the code.

That seems to be the reason its not working, and a pointer to the correct fix.

If two modules import each other, it doesn't work automatically.

It should do.

Some "where to put stuff" issues:

biggest one is a) can it put the .hi and .hbc files in the correct place
and b) can it run yhi in the directory of the test (so file IO works) if
you want an example that's currently broken then do: tester -dead
../../tests/nofib/real/anna

Yhc is built by buildbot very often, these binaries should be prepackaged,
at least on Windows, where users like this kind of thing.

Yhc does not have a Core library, other than the very informal one used by
Catch. The advantages to a Core library are:

1) Proper versioning in the Core library
2) Binary serialisation, much much faster
3) More portable

The haddock documentation is incomplete - methods which don't have type
signatures are omitted, some of the comments are not haddock-ified, some
modules export too much.

Samuel is currently working on this.

What steps will reproduce the problem?
1. Try compiling any project pretty much
2. Cry when you find that Data.Map etc are not available

It's annoying, its ugly, it requires an extra step for install, its just
generally yuk!

I've just tried explaining to someone on #haskell IRC why this is required,
needless to say its hard to give a convincing argument.

.lhs files won't go through haddock, they need to be "delitted" (using
cpphs), then processed.

Yhc has many back ends (Python, Hat, .NET, Java) - it would be nice if
those which work were in buildbot, subject to the machines having the right
setup.

What steps will reproduce the problem?
1. Download the Windows snapshot
2. Put Yhi in C:\Neil\yhc-snapshot\bin
3. Set your Path to

%GTK_BASEPATH%\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem
;C:\PROGRA~1\ATT\Graphviz\bin;c:\bin;C:\ghc\ghc-6.4.2\bin;C:\Program
Files\QuickTime\QTSystem\;C:\Python24;C:\ghc\ghc-6.4.2;C:\Program
Files\Subversion\bin;C:\Program
Files\WinHugs;C:\ghc\ghc-6.4.2;C:\msys\1.0\bin;C:\Neil\yhc-snapshot\bin

What is the expected output? What do you see instead?
Expected it to work, what happened:

C:\temp>yhi Main
ERROR: couldn't neither find environment variable YHC_BASE_PATH nor find yhi in
the PATH!

We should use binary .hi files where possible, to get a bit speed up.

There is no way with the build system to install the compiler as though you
wanted to use it. On Linux this should copy this over, put it on the path
location etc. On Windows this should set up the environment variables and
probably drop it in Program Files or something.

This is required for people to actually use Yhc.

What steps will reproduce the problem?
1. Go to http://www.cs.york.ac.uk/fp/darcs/yhc-devel/src/

What is the expected output? What do you see instead?
I expect to see the folder, I get 403 forbidden

Works for http://www.cs.york.ac.uk/fp/darcs/yhc-devel/,
http://www.cs.york.ac.uk/fp/darcs/yhc-devel/build/

I guess this is a permissions problem, so will take Tom or Andrew to fix.

We need Cabal integration, both so you can compile files using Cabal, and
so we can build the standard libraries.

Sometimes (every so often) about 20 patches are listed as triggering
buildbot. This is probably an overflow issue in the RSS parser.

During "scons test" YHC_BASE_PATH is set to "inst/bin"

This is bad because the test needs it to be absolute. Hacky workarounds
have been added to the test suite, so fixing this will probably break the
test (but then the test can be fixed properly!)

Scons assumes that Flags.hs is a dependancy of most things, however really
its only Flags.hi that is the dependancy, as if the interface doesn't
change (usual) less building needs to be done.

To reproduce:
Add one insignificant whitespace to Flags.hs
scons build yhc

Note that almost everything gets rebuild, while it should be just Flags.

The build system should parse pragmas from the library files as a stop 
gap measure until the parser supports it internally (see Bug #4). 

We have info all over the place, the primary website is officially:
http://www-users.cs.york.ac.uk/~ndm/yhc/, but thats a bit out of date, has
wrong info on etc. Move over everything on that to the wiki, then set that
page to be a redirect.

What steps will reproduce the problem?
1. Create a literate Haskell file, extension .lhs, with bird ticks
2. yhc File.lhs

What is the expected output? What do you see instead?
Expect successful compile, failed with parse error
Specifying the -unlit flag fixes this, but should be unnecessary

I just tried some uses of the "default" keyword with Yhc that failed,
and I didn't find any existing Yhc test-cases for this keyword. These
all run with Hugs.

Fails with Yhc:
- ----------
import Ratio (
 Ratio -- :: * -> *
 )
default (Ratio Integer)
main = putStrLn "okay"
- ----------

but works with Yhc:
- ----------
import Ratio (
 Ratio -- :: * -> *
 )
type RatioInteger = Ratio Integer
default (RatioInteger)
main = putStrLn "okay"
- ----------


Fails (differently) with Yhc:
- ----------
default(Rational)
main = print (0.1 * 3 == 0.3)
- ----------

but works with Yhc:
- ----------
default(Rational)
main = print ((0.1 :: Rational) * 3 == 0.3)
- ----------


Isaac

P.S. I know that type Rational = Ratio Integer

Windows currently uses the Visual Studio C compiler, it would be nice (but
entirely non-urgent) if it could be persuaded to use GCC.

Yhe hasn't had much love in a while, but someone just told me they built it
successfully using the existing makefiles. Before we remove the makefiles,
it would be nice for Yhe and GYhe to be building once more.

What steps will reproduce the problem?
1. Open an ordinary terminal
2. Try to build Yhi
3. Note that it doesn't work
4. Get annoyed
5. Start Visual Studio Command Prompt

What is the expected output? What do you see instead?
Would be nice if it could parse the appropriate vsvars32.bat file, get the
environment variables, and use that. Makes for a much nicer Windows
compiling experience.

Building on a PowerPC machine assumes that it's running Mac OS X. 

This may not be the case as Linux and FreeBSD both run on PPC, amongst 
others. 

What steps will reproduce the problem?
1. Build the yhc compiler
2. Fiddle with the code such that the dependency tree changes
3. Try doing 'scons' and notice that the build fails with out of order  
   dependencies
4. Try doing 'scons clean' to remove the dependency tree information
5. Try to rebuild but the depencies are still not recalculated.


In short it's a request for 'scons build compiler-deps' or that 'scons
build compiler' will recalculate the dependencies :-)

This bug is purely to test the bug track mailing list.

What steps will reproduce the problem?
1. Try compiling Yhi with VS 2005

What is the expected output? What do you see instead?
Doesn't work

Mike has this on his machine, test as soon as he returns from exotic beaches.

Feature request, have a release=1 flag to compile Yhc with -O and Yhi with
-O2. Ideally the Windows buildbot should have release=1 specified, if we're
going to release snapshots from it.

Possibly this flag could be combined with debug=1 to make
type=release/debug/normal - but thats not necessary. If debug symbols can
exist in an optimised binary it might be useful in case we run into weird
corner cases with -O2 binaries.

When run, the tester returns an error if any test fails. It should have a
list of tests which are expected to fail (different per platform), and only
error for the rest, so it is easier to spot a failing test. Every test that
is expected to fail should have a bug report and number :)

The error is below:

gcc -o 
src/runtime/BCKernel/basepath.o -c -DX86 -Wall -I. -I/usr/local/include 
-I/opt/local/include -Idepends/ctypes/libffi/include 
-Idepends/ctypes/libffi/src/x86 
src/runtime/BCKernel/basepath.c
src/runtime/BCKernel/basepath.c:20: error: conflicting types 
for 'asprintf'
/usr/include/stdio.h:296: error: previous declaration of 'asprintf' was 
here

Provide a Yhc.Make library, suggested functions:

makeInit - collect all useful information, Yhc base path etc.
getImports - what are the modules imported by this module
findFile - take a relative file, and an import System.Directory and return
a concrete FilePath

Makes a bit more of our logic more clearly defined, allows reuse for
hmake-style programs, allows more use for dependancy analysis for scons build.

From David Frech: 

[david@stubb ~/yhc-devel]$ scons fullclean 
scons: Reading SConscript files ... 
Checking for architecture... x86 
scons: done reading SConscript files. 
scons: Building targets ... 
scons: Nothing to be done for `fullclean'. 
scons: done building targets. 
[david@stubb ~/yhc-devel]$ scons 
scons: Reading SConscript files ... 
Checking for architecture... x86 
Checking for operating system... uname: illegal option -- o 
usage: uname [-aimnprsv] 

Checking for Scons binary... "/usr/local/bin/scons" 
Checking for Scons version... Found version 0.96.1.D001. 
Checking for Darcs binary... "/usr/local/bin/darcs" 
Checking for Darcs version... Found version 1.0.5 (release) 
. 
Checking for Subversion binary... "/usr/local/bin/svn" 
Checking for Subversion version... Found version 1.3.0. 
Checking for GHC binary... "/usr/local/bin/ghc" 
Checking for GHC version 6.4.1 or later... Found version 6.4.1. 
Checking for C header file gmp.h... no 
Error. libgmp must be installed and gmp.h made accessible before you 
can compile Yhc. 

Tester does a scan of the directories, then assigns numbers.

This means that the order that tests are in the directory structure (which
is file system specific), creates the test numbers.

The list should be sorted first to ensure consistent numbering and run order.

We don't have a Gentoo ebuild yet, we should, at some point.

darcs get http://haskell.org/~gentoo/gentoo-haskell/ --partial

The Gentoo Haskell Team (dcoutts on IRC) says if we send a patch, they'll
take it up, maintain it, and get it into portage for us.

What steps will reproduce the problem?
1. make sure the tester is built
2. cd src/tester
3. ./tester -dead ../../tests/nofib/real/rsa

What is the expected output? What do you see instead?

It should pass but in essence it fails with:

ERROR: couldn't find module named '_Builtin'
tried:
        _Builtin.hbc

/home/tom/work/yhc-devel/inst/lib/yhc/packages/yhc-base/1.0/_Builtin.hbc


Diagnosis:

_Builtin has been removed since the change to libffi, it's likely there is
some 'primitive' lying around in the library source that is causing
_Builtin to get pulled in (which fails).

The snapshots should be in both .zip form, and with an installer.

The installer should:

Extract the .zip file
set YHC_BASE_PATH
add Yhc/Yhi to the PATH (optional)

Not much point til Bug 7 is fixed.

Rerun the graph for runghc, ghc, ghc -O etc.

Hopefully move to having the Yhc C generator in there too. Perhaps the
Python/.NET one as well.

Should work like GHC:
http://www.haskell.org/ghc/docs/6.4.2/html/users_guide/pragmas.html#options-prag
ma

Can be fixed by changing the parser (yuk!) or simply parsing with lines the
file first.

As a first step, the build script should add parsing support for this.

We have info all over the place, the primary website is officially:
http://www-users.cs.york.ac.uk/~ndm/yhc/, but thats a bit out of date, has
wrong info on etc. Move over everything on that to the wiki, then set that
page to be a redirect.

What steps will reproduce the problem?
1. make sure the tester is built ('scons test')
2. cd src/tester
3. ./tester -dead ../../tests/nofib/imaginary/x2n1

What is the expected output? What do you see instead?
It should pass, but fails with:

    -- TEST (1/1) -
    /bin/sh: line 1: 23397 Aborted                 yhi     
    ../../tests/nofib/imaginary/x2n1//Main  
2>../../tests/nofib/imaginary/x2n1//actual.stderr
>../../tests/nofib/imaginary/x2n1//actual.stdout
    ERROR: different stdout
    EXPECTED:
    10000

    ACTUAL:

    ERROR: different stderr
    EXPECTED:

    ACTUAL:
    yhi: src/runtime/BCKernel/mark.c:115: mkt_isMarked: Assertion `w >= 0
&& w < G_markTableSize' failed.


It's likely some obscure GC bug in yhi.