- Nhc-users - Haskell.org

Lista de emails emails de pessoas enviar emails
by Ed Soares 23 Nov '13

23 Nov '13

Lista de emails emails de pessoas enviar emails email cadastro incluindo lista de emails, email lista gratis enviar email: http://www.maladiretaemails.com pode ser que como fazer um email marketing, é uma boa para muitos. list mail trabalho com mala direta que incluem lista de emails, listas de email o que e mala direta, é realmente a função de nosso Site. No caso de você está buscando lista de email, email lista gratis assim como emails de empresas: http://www.maladiretaemails.com é bastante legal newsletter que contenham servidor de email, list mail listas de emails. é incrivelmente importante lista de emails e também email de marketing. email em massa lista emails gratis, envio de emails. neste momento enderecos de email além Enviar email, email mailing é fantástico. a intenção de nosso website: email lista gratis, Enviar email, além de mala direta em casa. Nós fornecemos enderecos de email mala direta em casa, email em massa.

1 0

Rela��o de aprovados Belo Monte
by Edson 29 May '13

29 May '13

Relação de aprovados Belo Monte: Poxoréo: ALINE RAQUEL BEZERRA LEITE, LEANDRO DO NASCIMENTO BATISTA, FERNANDO MONTEIRO DOS SANTOS, NEYLSON CAVALCANTE DOS SANTOS, JOÃO CARLOS MOREIRA DE CARVALHO, CLEVILSON PEDRO FONSECA OLIVEIRA, MARIA DE FATIMA ALEIXO PINHEIRO, IVETE CORDEIRO DE SOUZA. SAMILLE DE OLIVEIRA CAVALCANTE, ELISÂNGELA DOS SANTOS SILVA, MAURY DE SIQUEIRA MELO PEREIRA, JOSEFA LIDIANA ALVES FERREIRA, VITOR HUGO OLIVEIRA SOUZA. João Lisboa. Belo Monte, ANDERSON BEZERRA MOURAO, LUCAS CAULA ALBUQUERQUE, GEILSON HOLANDA SAMPAIO, RAFAEL FERNANDES, JOÃO CARLOS MOREIRA DE CARVALHO, DEBORA CRISTINA SCHNORNBERGER, MARIA MACLENE BEZERRA LIMA, JOAO PEDRO TAVARES MAGALHAES. TAMYRES AMORIM SOUZA, CAIO CESAR FERNANDES LOPES, MAGNUN SANTOS FREDERICO, IAGO SIMOES CALIARI, RITA MARIA SILVA ALMEIDA. Cachoeira de Minas. Nova Canaã e ANA KARINE PAULINO DA SILVA, LUAN VICTOR VASCONCELOS NOBERTO, FRANCISCO MARKAN NOBRE DE SOUZA FILHO, PEDRO SIQUEIRA FONTENELE, JOÃO CARLOS MOREIRA DE CARVALHO, DANIEL MOREIRA ALVES DA SILVA, MARIA JOELMA BEZERRA DA SILVA, JESSICA DE PONTES GOMES. SINELANDIA MARIA DA SILVA, BRENA CARLA DE MELO CAMELO, LUCINEIDE MARIA DA SILVA, HAROLDO PEIXOTO DA JUSTA JUNIOR, RENATA ROCHA DE NEGREIROS. Itapaci.

1 0

Re: porting nhc98 to plan9
by Fernan Bolando 12 Sep '09

12 Sep '09

On Thu, Sep 10, 2009 at 3:57 PM, Malcolm Wallace <malcolm.wallace(a)cs.york.ac.uk> wrote: > Hi Fernan, > >> Aside from below code. I am also having problems compiling hc files with >> #define CT_v249 ((void*)startLabel+464) > > By way of explanation, the idea of these symbols is that the bytecode > sometimes needs to refer to an indexed position elsewhere in the bytecode. > If the indexed position needs to be visible externally (to this module), it > is declared like > >> unsigned F0_Prelude_46primLeave[] = { > > but in the cases where it need only be visible internal to the module (e.g. > a constant table (CT) associated with a function), we use an address > calculation instead: > >> #define CT_v249 ((void*)startLabel+464) > > In both cases, it is important that the bytecode be continuous, that is, in > a sequence like > > , bytes2word('u','p','l','e') > }; > unsigned PC_Prelude_4618[] = { > bytes2word('P','r','e','l') > > it is necessary that the bytes are really in the sequence > > 'u','p','l','e','P','r','e','l' > > The symbol PC-Prelude_4618 refers to the middle of this sequence - it should > not start a new section of memory, separated from the previous section. > > >> It appears that it is trying to pointer addition with a void*. This is >> ok with gcc as a >> "non-standard extension", but it will not work with plan9. >> >> So far I did this to make those section compile >> >> 1. changed userLabel define >> --#define userLabel(fun) ((unsigned)fun) >> ++#define userLabel(fun) ((unsigned*)fun) >> >> 2. removed void* pointer addition by writing a script >> from #define CT_v249 ((void*)startLabel+464) >> to #define CT_v249 ((unsigned char*)startLabel+464) > > OK, that seems like a reasonable change - it should preserve the invariants > I described above. > > If you manage to get nhc98 bootstrapped on plan9, do please send your > changes to me, so that I can incorporate them into the main nhc98 tree - > then everyone else can benefit too. > Hi Malcolm Thank you for your explanation of the bytecode. I really havn't understand the nhc98comp operation yet. I am basically just running the c files through the plan9 compiler and fix what ever issues come up. I am still doing a lot of guessing here, but I a few more questions. 1. The hc files are generated by nhc98comp? I will still need to modify nhc98comp to always produce the unsigned char*? 2. I am also bypassing nhc98 script during the prelude build. I am created a separate script to compile prelude under plan9. The script just loads the hc files into the C compiler. 3. I am still guessing here, but If item 2 is an ok approach is it possible to simply compile src/runtime/Runtime.a and use the .o files from a unix build? thanks fernan -- http://www.fernski.com

2 2

porting nhc98 to plan9
by Fernan Bolando 08 Sep '09

08 Sep '09

Hi all I am trying to look into porting nhc98 to plan9. Plan9 has only two C compiler and it doesnt support all the C capability available in Unix due to the difficulty in emulating some areas of unix into plan9. So far getting some section of nhc98-1.20/src/runtime compiled works ok, but I had to a do some minor changes on the section of code below. The C preprocessor coudn't determine the value of the initializer for F0_Prelude_46primLeave[], giving the error "initializer is not a constant for F0_Prelude_46primLeave". I tried to hard code the value, but was not sure if my number is correct, so I wanted to get first hand information. --snippet from newmacros.h --- #define VAP_TAG 1 #define WORDSHIFT 5 #define WORDSIZE (1<<WORDSHIFT) #define WORDMASK (WORDSIZE-1) #define NS (WORDSIZE>>3) #define ZAP_BIT (1L<<(WORDSIZE-1)) #define CAPTAG(fun,need) useLabel(fun) - (NS + 2 + (2 * need)) + VAP_TAG #define useLabel(name) ((unsigned)name) ---- -- snippet from newbuiltin.c ---- unsigned F0_Prelude_46primLeave[] = { CAPTAG(FN_Prelude_46primLeave,1) #ifdef PROFILE , useLabel(PROF_primLeave) , 0 , 0 , 0 #endif -- regards fernan -- http://www.fernski.com

1 0

Re: [nhc-users] fps and Foreign(Obj/Ptr)
by Donn Cave 05 Nov '08

05 Nov '08

Quoth Don Stewart <dons(a)galois.com>: [... re ByteString performance ] | I'd imagine there's others where space is a premium, where it would be | no contest to use a packed representation. Right, that was the initial attraction. I'm trying to put something together to exercise a little IMAP parser, and that means chunks of data that are potentially large enough that people worry about whether the size value could be larger than 32 bits. So it makes sense to use ByteStrings from the start - starting with socket input. At the other end, selected bits of data go to the C++ UI, and that's the other place where String isn't much use. That's where I was running out of foreign objects, and the larger foreign[] does help, thanks! Now I see I have a leak, though - the foreign objects are piling up where I was hoping they'd be gc'd, so I have more work to do. Maybe complicated by the fact that the Haskell producer and C++ consumer of these data are in separate threads, but I don't think that's my immediate problem. I bet if all Haskell objects were allocated in a fixed 1024 element list, people would notice space leaks much more quickly and reliably! Donn Cave, donn(a)avvanta.com

1 0

fps and Foreign(Obj/Ptr)
by Donn Cave 05 Nov '08

05 Nov '08

I've run into a problem where it looks like my application crashes with "Error: allocation limit (1024) exceeded for Foreign(Obj/Ptr)" because it's using too many ByteStrings. Does that seem plausible? Can I simply increase the size of that foreign[] array, by several orders of magnitude, to get around this? thanks! Donn Cave, donn(a)avvanta.com

3 2

Re: [nhc-users] FFI "wrapper"
by Donn Cave 16 Oct '08

16 Oct '08

Quoth Malcolm Wallace <Malcolm.Wallace(a)cs.york.ac.uk>: ... |> While I'm at it - if I manage to get callbacks working - they'll be |> coming from various different OS-level threads, so ... I will need to |> protect against concurrent execution, right? | | nhc98's runtime system is single-threaded, but assuming that the | functions you export are pure, I don't see how that is a problem. I | suppose you would need somehow to route all callbacks into the OS thread | that contained the (single) nhc98 runtime system? Well, I suppose that's a possibility, though it would further limit what I could do within Haskell of course. I'm working (or playing would be more accurate) with the Haiku operating system, essentially same API as BeOS from the '90s. Not yet even to the alpha release, so I'm not offended if you find the platform obscure. Its user interface uses threads, one per window, and sends messages to the window message port for user input etc. The API is C++. Just to see what would happen, I put together the trivial beginning of a hybrid C++/Haskell application, with roughly a 5 layer structure - 1 Haskell: trivial main, for runtime 2 C++: application main thread, and 1 window thread 3 Haskell: from window callback, and Haskell in independent thread 4 C: utility wrappers 5 C++: utility functions The window call back runs in the window thread, of course. The other Haskell thread handles "the configuration" - send it a message asking about some configuration attribute, it replies with value of that attribute. The configuration data accumulates in this thread's receive/send loop, avoiding the need for module-global, mutable configuration state that I don't know how to implement. If I wouldn't do that in a real application, I would sure do the same kind of thing with a service socket connection, for example - i.e., use a separate thread to avoid stalling the whole application waiting for network input, and use messages to communicate with it from other threads. It worked fine until I added that Haskell thread. The only problem then is that on normal termination of the application, the top level Haskell "main = cmain" will actually go on after "cmain" returns, jumping to where the configuration thread was, waiting for input from the message port, when it died. I can fix that by calling exit() from cmain(), rather than returning, so at this point it's just a curious behavior. But I'm probably asking for trouble, working the runtime concurrently from different threads, and the only reason it seems to work as well as it does is because there isn't any actual concurrent computation in this example program. So what I expected I would have to do, was something similar to what Python and I believe ocaml do, a thread interlock that serializes access from different threads to the runtime, The thread that holds the lock runs until an I/O operation, then releases the lock, and tries to get it back after the I/O completes. Now that I think about it, I guess that would mean among other things that I couldn't use much native Haskell I/O, but I'm not far away from that anyway. I'm thinking it doesn't matter if different threads are involved with the runtime, as long as it isn't concurrently. Donn Cave, donn(a)avvanta.com

2 1

FFI "wrapper"
by Donn Cave 08 Oct '08

08 Oct '08

Just this weekend I got nhc98 running on a platform where I've wanted a Haskell compiler for a long time, very thrilling. But of course nothing's ever perfect, and apparently there's no foreign import "wrapper" support, which I think is what I would use to pass Haskell functions to C. Is there another way to do that? I'm looking at a C++ API where a class virtual function would call back to a different function for each class instance object, so while "foreign export" is a start, it doesn't do what I need to do. While I'm at it - if I manage to get callbacks working - they'll be coming from various different OS-level threads, so ... I will need to protect against concurrent execution, right? Thanks! Donn Cave, donn(a)avvanta.com PS The platform is a revived/cloned open source version of BeOS, called "Haiku". Haiku hasn't actually been released yet, but I've run BeOS since it came out ca. '96. I'm sure I'm not the only one who has ever wanted to compile Haskell on BeOS, but likely one of only a handful.

2 1

Help needed with a compiling error
by HP Wei 22 Apr '08

22 Apr '08

compiler: nhc98-1.18 on Sun sparc machine code-to-compile: the one near the end of this web page: http://cgi.cse.unsw.edu.au/~dons/blog/2006/12/18 [ I cut-and-paste it into a file called cat.hs ] command invoked: nhc98 -o cat cat.hs nhc98 -package base -o cat cat.hs [ both give the same result. ] The last line of total 4 lines of output looks like: Fail: superclassesI InfoUsedClass 52 [(Type class, Text.Printf.PrintfArg, "ftnirP.txeT", 52:11-52:19)] ... Could someone tell me what I should do to fix the problem ? Note: the same code can be compiled with ghc6.8.2 [ but I have to repalce withFile with withFile1 in cat.hs ]. I am using nhc98 so that the binary-code generated can be small. Thanks HP

2 1

nhc98 as a cross-compiler, and further work
by sylvain nahas 03 Apr '08

03 Apr '08

Hi, I had no much time for working further on the patch to convert nhc98 to a cross-compiler, but I do intend to finish this project before the end of this week. Afterwhile I plan to implement the possibility of linking executables against shared libraries (.so) instead of static ones. Do you know of technical problems that could hinder this ? Any suggestion ? BTW, HEAD of darcs repository still doesn't build, isn't it ? As far as I can tell, some files are lacking. I feel quite uncomfortable to patch against an older release. Cheers, Sylvain

1 0