similar to: ghc and xmonad

Hello I threw together some Seamonkey 2.0 rpms for i386 and you can grab them from here http://lostsonsvault.org/dls/centos/ I dont have a 64 bit one yet but if someone would like to rebuild the src.rpm for 64 I will gladly host it, thanks. LostSon

Hello A few weeks ago I started having problems with my system email or specifically my logwatch reports showing up in my inbox. I got most of those issues figued out except one now when i get an email from my system it has a title of this Cron <root at localhost> run-parts /etc/cron.daily with this message /etc/cron.daily/0logwatch: Recipient names must be specified I have my

Hey I was wondering how i can become a proof reader for the newsletter ? I speak and read native english as it says in the wiki. -- LostSon http://lostsonsvault.org CentOS - It's not just for servers ya know... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed

Hello I am curious about some articles I would like to contribute to the wiki. I would like to add some articles about installing games, like UT, Quake3 with the Urban Terror mod and Enemy territory. The question I have is are these articles something that the group would like on the wiki ? I know CentOS is more aimed at servers and sysadmins than home user but there are some of us out there and

Hello I was wondering if someone could put together a bug triage guide and put it on the wiki. I was looking for something to do tonight and z00dax said go hunt some bugs. So I went first to the wiki to look for a guide for a proper procedure on how the team would like bug triaging handled but didn't find one. I have triaged before but i know every place is different. So some guidelines

Hey all I was sitting here thinking about things and I came up with an idea that sounded, at least in my head, like a good one. There has been a boom in things like twitter and brainbird and social networking setups in general. I was wondering if the project or anyone would be interested in setting up a status.net server specifically for the CentOS project ? Why? you ask, well here are some of

Hello All I may have ruffled some feathers with a comment i made earlier about rpmforge. This was posted back on the ML. On Tue, 2010-01-12 at 14:47 -0600, lostson wrote: > For one stop using rpmforge this repo does nothing but trash a system. Discussion on that for us? So to oblige here is a further discussion on this subject. The reason I say this about rpmforge is because if you

http://bugs.freedesktop.org/show_bug.cgi?id=20466 Summary: No borders in Xmonad/Dwm Product: xorg Version: 7.4 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy:

Hello Attached is my idea for a nvidia wiki page hopefully this is informative and good enough for the wiki, ideas and critique welcome of course, thanks. -- LostSon http://lostsonsvault.org CentOS - It's not just for servers ya know... -------------- next part -------------- ## my proposed nvidia guide wiki page ## If you have a nvidia card and wish to use it with centos than follow

Hello, today is the last day[1] when someone might ask for feature merge into the LLVM 3.0 release. I'd like to ask you to merge attached patch. This is implementation of GHC calling convention on ARM platform which is made by Stephen Blackheath with few additions by me. I hope that although the patch does not contain any test case, it still will be merged. The reason for this is that

David, Thanks for that - I emailed Karel Gardas. I've got GHC successfully registerised on ARM, and I'm just starting on pushing it upstream. The reason why I'm avoiding the R0-R3 registers is mainly because my qemu-based ARM VM takes days to compile everything, and I was being conservative. The GHC code can call directly out to C, so it would need to save its own R0-R3 when it

OK, new patch attached. Hopefully in time for 2.7. Chris Lattner wrote: > 1) is the GHC calling conv intended to be target specific? If it is x86 specific, it should get an X86 prefix. If not, it should move up to be #10 after Cold. No its intended to be supported on any platforms that GHC is supported on, which is just x86 and SPARC at the moment. At the moment I've just done X86, will

Hi Steve, I'm not an LLVM developer but am the author/maintainer of the LLVM backend in GHC. The patch looks mostly good to me (although I am not that familiar with ARM so could easily have missed something). My main concern is why are you avoiding using the R0 - R3 registers? Also, could you please update me on the status of this work. I assume you are getting GHC running in registerised

On Jun 24, 2012, at 7:18 AM, Karel Gardas <karel.gardas at centrum.cz> wrote: > > Hello, > > first of all: one of the LLVM 3.0 new feature was a support for GHC specific calling convention on ARM platform. It looks like this support was merged just into 3.0 branch, specifically it appeared in 3.0 RC2. > Anyway, I hope this is just a mistake or omission that such support was

On Mar 2, 2010, at 5:33 PM, David Terei wrote: > Hi all, > > As previously mentioned on this list the Haskell compiler GHC has a new LLVM based back-end. The back-end needs a new calling convention to efficiently use LLVM and that is what this patch does, just for X86 at the moment. Nice, > The GHC developers would love to get this included in LLVM so that we don't need to

Hi Duncan, Karel, On 14 October 2011 08:22, Duncan Sands <baldrick at free.fr> wrote: > Hi Karel, > >>>> > const unsigned* >>>> > ARMBaseRegisterInfo::getCalleeSavedRegs(const MachineFunction *MF) >>>> const { >>>> > + bool ghcCall = false; >>>> > + >>>> > + if (MF) { >>>> > + const

On 06/29/12 11:12 PM, Renato Golin wrote: > On 29 June 2012 17:46, Karel Gardas<karel.gardas at centrum.cz> wrote: >> Yes and no. Shortly: original GHC/ARM/LLVM port was done by Stephen on >> ARMv5/Qemu IIRC. I've later added whole VFP support and ARMv7 support. The >> code in GHC is properly #ifdefed, so if there is no VFP available on pre >> ARMv6, then

I found a fix! The first hunk of https://reviews.llvm.org/D17533 (lib/CodeGen/TargetFrameLoweringImpl.cpp) on top of 3.8.1 does the trick. Does llvm do patch releases of old versions? Davide Italiano <davide at freebsd.org> writes: > On Fri, Oct 21, 2016 at 6:19 AM, Shea Levy via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi all, >> >> I'm hitting

All, I would like to submit the attached patch, which allows the GHC (Glasgow Haskell Compiler) calling convention to work on ARM targets. Could some nice person please review this code, so I can move towards getting it committed? I have thoroughly tested this patch again GHC on a Debian-ARM (armel) system. Unfortunately my understanding of LLVM is limited, so it's likely I'm not

On 29 June 2012 17:46, Karel Gardas <karel.gardas at centrum.cz> wrote: > Yes and no. Shortly: original GHC/ARM/LLVM port was done by Stephen on > ARMv5/Qemu IIRC. I've later added whole VFP support and ARMv7 support. The > code in GHC is properly #ifdefed, so if there is no VFP available on pre > ARMv6, then it's not used. ie. GHC STG floating points regs are then >