he extcore and linkcore libraries:
http://hackage.haskell.org/package/extcore
http://hackage.haskell.org/package/linkcore
IMO, it's easier than using the API to generate Core. If you find any
problems with External Core or the packages above, let me know (I'm
the maintainer).
Cheers,
Tim
would be a research project in and of itself. Part
of that project would involve specifying exactly what "the original
Haskell expression" means -- for example, in the presence of
aggressive inlining...
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in do
count for much, but a switch to git would be one more small
thing that would discourage me from contributing in the future.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt
"an intelligent person fights for lost causes,realizing that others
are me
ply, but have you considered using External Core?
http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/ext-core.html
http://hackage.haskell.org/package/extcore
IMO, it's less pain than linking with the GHC library unless your
application really needs to get transformed Core back into the GHC
bac
helping out, you could add
your procedure to the wiki: http://hackage.haskell.org/trac/ghc/wiki
If you have any followup questions, please reply to me and CC the
mailing list, as I don't always read the mailing list, but it's also
good if replies are on the record.
Cheers,
Tim
--
Tim
sappeared
into the aether :-)
Cheers,
Tim
--
Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
“I cannot hide my anger to spare you guilt, nor hurt feelings, nor
answering anger; for to do so insults and trivializes all our efforts.
Guilt is not a response to anger; it is a resp
Have you tried using the INLINE pragma?
http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#inline-noinline-pragma
Cheers,
Tim
--
Tim Chevalier* catamorphism.org *Often in error, never in doubt
"You have not proven yourselves smart enough to act that stupid all
the time an
work, you need the HEAD (or a recent nightly build
snapshot). If it's still not working after that, post again.
Cheers,
Tim
--
Tim Chevalier* catamorphism.org *Often in error, never in doubt
"More than at any other time in history, mankind faces a crossroads.
One path leads to despair
n "./myProgram +RTS -N4 - rmyout.ticky" ?
I haven't tried it, but the best way to find out is to try it and see
:-) If you run into problems, yell.
Cheers,
Tim
--
Tim Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt
___
Glasgow-hask
On 8/2/07, Tim Chevalier <[EMAIL PROTECTED]> wrote:
> I'm forwarding this to ghc-users since nobody answered on
> haskell-cafe, and I'm still curious... (The original message is at
> http://www.nabble.com/Lazy-in-either-argument--t4133855.html)
>
Replying to myself aga
I'm forwarding this to ghc-users since nobody answered on
haskell-cafe, and I'm still curious... (The original message is at
http://www.nabble.com/Lazy-in-either-argument--t4133855.html)
-- Forwarded message ------
From: Tim Chevalier <[EMAIL PROTECTED]>
Date: Jul
t;
Yes, but I found it surprising that just removing a type signature
should result in markedly different code. Are there other known
situations where that can happen?
Cheers,
Tim
--
Tim Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt
___
t;
Right, both programs result in the same runtime behavior if
optimizations are turned on. (Which, of course, is another surprising
thing: the program with the type signature omitted loops if compiled
with -Onot and terminates if compiled with -O.)
Cheers,
Tim
--
Tim Ch
ed when
optimization is disabled (if you don't pass in any optimization flags
like -O, it's like saying "don't do any optimization"). Don't expect
GHC to generate efficient code with optimization turned off :-)
Cheers,
Tim
--
Tim Chevalier * catamorphism.org * Often in err
GHC?
http://hackage.haskell.org/trac/ghc/wiki/Building/Windows (there are
some special procedures here for Vista users).
Cheers,
Tim
--
Tim Chevalier * catamorphism.org * Often in error, never in doubt
"Knowledge was power, as long as one did not muck it up by confusing
one piece of knowle
thing?
Cheers,
Tim
--
Tim Chevalier * catamorphism.org * Often in error, never in doubt
"Research is what I'm doing when I don't know what I'm
doing."--Wernher von Braun
___
Glasgow-haskell-users mailing list
Glasgow-haskell-u
h some of the
> spam.
>
Looks like that's not quite enough:
http://hackage.haskell.org/trac/ghc/wiki/WikiStart?action=diff&version=105&old_version=104
I rv'ed that one -- just a heads-up, since if there's spam now, there
will be more spam later.
Cheers,
Tim
--
n me to finish it :-)
Also, writing out Core is working in the HEAD -- what remains to be
done is to finish the work on reading it back in.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"...People who mind their own business die of boredom at
thir
esulting Core bindings
The API can do this already :-)
> - now glom all those bindings together and optimize
> - code generate, write out a .o file
>
I'm working on this part. In fact, I'm almost ready to check it in --
at least for the single-module case.
Cheers,
Tim
--
ntract debate, there's nothing in the
Big-Kazooba-Ritual license that seems to violate the usual principles
for a unilateral form contract, probably because no lawyer would ever
think up something that perverse :-)
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in erro
rom an external file
will take more effort, although I plan to work on it soon.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"Faith, faith is an island in the setting sun / But proof, yes, proof
is the bottom line for everyone."--Paul Simon
;t take
care of this for me for package modules.) The main tricky bit for me
has been dealing with GHC primitives. There are a lot of them. I don't
know whether Catch needs to know what the semantics of the primitives
are, though.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in
gt; Moving -i to other places still gives the same behaviour. Does
> package-name base also imply other flags (perhaps -i. ?) which are
> negatively effecting my particular use.
>
I don't know, but in GHC (as opposed to GHCi), it all works. I can
post some sample code if that would
ole. Are the semantics of __letrec different
> from let in some way?
>
How are you printing out the Core? It looks like the unique ids are
missing (you can see them if you pass the -ppr-debug flag, which can
be set using the API) -- if the unique ids were being printed, you
would see tha
t;
Yes, but you'll need to grab a post-Dec-25 build if you haven't
already, since I added this recently. Once you have, see
compileToCoreSimplified in main/GHC.hs.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"It's
lenty of
other interns around to keep me company even during the fall, and
Cambridge is a lovely place to spend an autumn as well.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"The more you talk, the more I get / a sense of something that hasn't
h
e debug.. this is not release-quality code
> though).
>
> Any idea what is going on here?
>
This would probably be a better question for ghc-users, since that's a
lower-traffic list for GHC-specific questions. Redirected there.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc
uctural and safety issues these days, so perhaps
> that is ill-advised...
>
It seems perfectly appropriate to me. *ducks and runs*
Also, this from Manuel's original message is just beautiful:
> Installation instructions: nil
I'm almost tempted to switch back to a Mac.
Cheers,
Ti
On 2/14/08, Yitzchak Gale <[EMAIL PROTECTED]> wrote:
> Manuel M T Chakravarty wrote:
> >> I'd also be nice to have a cool logo/icon.
>
>
> Tim Chevalier wrote:
> > I am a mediocre artist, but I'd be willing to give it a try if there
> > are
onal languages on stock hardware: the
Spineless Tagless G-machine, SL Peyton Jones, Journal of Functional
Programming 2(2), Apr 1992, pp127-202.
Then if anything's still not clear, ask on the mailing list.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~
Did you try comparing the results if you pass the -fno-state-hack flag?
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"I am never gratuitously rude. My rudeness is carefully calibrated to
the stupidity and obtuseness of the people I am dealing
hat's what you mean. The
following should pull patches and rebuild everything without manual
intervention:
./darcs-all pull -a; sh boot; ./configure; make
but YMMV.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"Aristotle maintained that wom
;t be
able to compile any programs without -ticky this way.
In the meantime, I'll look into making the "ticky" way work so that
it'll be possible to have ticky and non-ticky libraries coexisting.
If you have any more questions about ticky-ticky profiling, please CC
both me
re some build system hacking, which is an area I'm not familiar
with at all, so I can't give much advice about how to solve the
problem. You're welcome to try, though. I added a ticket at:
http://hackage.haskell.org/trac/ghc/ticket/2455
so if you make any progress, you should add a
e
keeps getting bigger, but that seems like a lot of overhead.
I can try to come up with a smaller test case if necessary; just
wanted to see if there's any known problem.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"The trouble with academia
t; Also a related q: why doesnt't the time spent in putStr show up?
>
You would have to rebuild your GHC libraries with the -auto-all flag
in order to get cost centres attached to library functions (but this
may defeat some optimizations).
Cheers,
Tim
--
Tim Chevalier * http://cs.p
programs, under utils/ext-core in the GHC distribution.
If you don't find it useful, and have any suggestions as to how it
could be improved, I would be interested to know; please CC both me
and this list if so.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in
via-C or -fasm. The Mac does have a lot
less RAM, but I can see that the program isn't swapping.
So is the PPC backend really this bad, or should I be looking for
something weird with the hardware or configuration on the Mac?
Thanks,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in er
the PC:
1.07s MUT time (1.34s elapsed)
0.01s GC time (0.02s elapsed)
%GC time 1.1% (1.6% elapsed)
so GC doesn't seem to explain the large difference in running times.
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"Maybe I don't want to meet s
a simple C loop
that I tried runs for 4.5s on the PC and 30s on the Mac. So probably
this isn't GHC's fault.
Thanks for the suggestion.
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"In fact, a sense of essence is, in essence, the essence of sense, in
e
tics for External Core) under utils/ext-core in the GHC source
tree. The version of Core described in the user manual is a little
different.
If you have questions about any of the abovementioned documentation,
please CC both me and this list, as I don't read the GHC lists often.
Cheers,
Ti
Hi,
Is there a way to tell the GHC build system that I only want to build
a stage 1 compiler and the libraries, not a stage 2 compiler?
Executing:
$ sh boot
$ ./configure
$ make stage=1
in my build tree still builds the stage 2 compiler as well.
Thanks,
Tim
--
Tim Chevalier * http
ove rebase3-compat (in the next few days, in the
> HEAD), the only thing that needs syb is extcore. Is that sufficient that
> it is worth keeping it as a core lib?
>
I've meant for a long time to split off the ext-core library and put
it on Hackage, since it isn't required to buil
that GHC uses externally, but not quite the same):
http://hackage.haskell.org/package/extcore
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"Do we learn from our mistakes? I surely hope not / Takes all the fun
out o
t, you can always ask here.
Cheers,
Tim
--
Tim Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt
Confused? See http://catamorphism.org/transition.html
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell
45 matches
Mail list logo
