Hello All,
I am trying to profile memory with bglmemrun but I can't get it work.
Here is my little test:
test.scm:
---
(module main
(main main))
(define (main argv)
(print "Ok"))
Compilation
---
bigloo test.scm -g2 -o test
Run
-
bglmemrun test
mem initializ
All
I have some issues concerning error-localization:
1) Bigloo is searching for /tmp/bigloo sources which seems strange for me
since I do not use this directory (even for compiling)
Error-localization shows crappy blank lines:
===
Regards,
Pierre
-Original Message-
From: bigloo-requ...@inria.fr [mailto:bigloo-requ...@inria.fr] On Behalf Of
Sven Hartrumpf
Sent: Wednesday, December 07, 2016 1:52 PM
To: bigloo@inria.fr
Subject: Re: [bigloo] Memory profiling with 4.3a
I wrote, 2016-12-07 08:10:
> Hi.
>
> "Oll
Hello,
I have an issue when compiling: The Dataflow+ fail and "remove" a part of the
code:
Unfortunatly I did not success to make a testcase Issue is probably coming
by the fact that several things are coming and used in several modules.
For information, it is working in 4.3a.
I have origin
son [mailto:donaldso...@yahoo.com]
Sent: Friday, March 09, 2018 5:44 PM
To: Ollagnon, Pierre-Francois ;
bigloo@inria.fr
Subject: Re: [bigloo] Dataflow+ debuging
Hello, Pierre-Francois,
Can you provide some more information? For example, what is the actual error
reported by the compiler and what
Hello,
Like clearly said in my previous mail, it is the "data-flow-types / dataflow+"
optimization step that fails.
-O2 is not working -O2 -fno-datatype is working.
But
1) I do not like to add specific compilation options for a certain module
because of a bug.
2) If it arrive here it can arrive
y: 2
import: local
Its seems that combination leads to my issue
Anyone can help to explain me what it means?
Best regards,
Pierre-Francois
From: Joseph Donaldson [mailto:donaldso...@yahoo.com]
Sent: Monday, March 12, 2018 7:32 PM
To: bigloo@inria.fr; Ollagnon, Pierre-Francois
Subject: Re
inal Message-
From: bigloo-requ...@inria.fr [mailto:bigloo-requ...@inria.fr] On Behalf Of
manuel.serr...@inria.fr
Sent: Wednesday, March 14, 2018 1:50 PM
To: Ollagnon, Pierre-Francois
Cc: bigloo@inria.fr
Subject: Re: [bigloo] Dataflow+ debuging
Hi Pierre-François,
I have bad time understanding
: Ollagnon, Pierre-Francois ;
bigloo@inria.fr
Subject: RE: [bigloo] Dataflow+ debuging
Hi Everyone,
I think the problem is now solved. I have uploaded the patch into the github
repository. When I have the confirmation that the problem is indeed solved, I
will try my best to prepare the 4.3c final
Hello all,
Is there any reason for which I get a different behaviour on this 2 functions:
1:=> (define (combination n s lst proc-to-apply)
(cond ((equal? n 0) (proc-to-apply lst)) ;;Final
((equal? s 1) (proc-to-apply (append (make-list n 0) lst))) ;;Final
((equal? n s)
.
I did not take the time to investigate on it but it’s on my to-do list.
Thanks for your quick reply to highlight my stupid mistake.
Best regards,
Pierre-Francois.
From: Joseph Donaldson [mailto:donaldso...@yahoo.com]
Sent: Friday, March 23, 2018 10:54 PM
To: Ollagnon, Pierre-Francois ;
bigloo
Hello Sven,
I confirm that it is a very good way to profile ...
Here are some tricks we are using:
1) You can profile only some parts of your code with
(include "valgrind/callgrind.h")
(define (start-profile)
(pragma::void "CALLGRIND_START_INSTRUMENTATION;")
#
Hello,
It's been a while that I have some random issue.
My understanding is that the methodoly used to abort something in the (repl)
using Ctrl-C is not "thread safe"
I have seen that when we launch functions making a lot of allocation, sometime
when we hit Ctrl^C the repl get stuck and every t
Hello,
Did anyone from Bigloo had the time to look at this issue ?
Thanks,
Pierre-Francois
From: Ollagnon, Pierre-Francois
Sent: Wednesday, August 12, 2020 4:00 PM
To: big...@sophia.inria.fr
Subject: Bug in GC (and maybe more) using pthread and (repl)
Hello,
It's been a while that I have
Hello Manuel,
I am using the latest 4.3c (I am switching from an old 3.1b ...) and I face
some issues so here is the first one:
;; (module test
;; (main main))
;; (define (main argv)
;; (mytest "test"))
(define (myprint v1 v2)
(print 'not-printed))
(define (mytest var1)
(do (
Hello Manuel,
I don't really know if this behavior is wanted or not:
If I define a function:
(define (test begin end)
(print begin end)
)
It Both can be loaded and compiled.
But at the execution I get:
*** ERROR:eval:
Type "procedure" expected, "bint" provided -- 1
1. test, stdin@574
I c
Hello again,
1)
I have a machine without "resolve" but when compiling bigloo 4.3c with the
option " --no-resolv"
the compilation of bigloo/runtime/Clib/cresolv.c is failing (undefined
reference to "ns_t_invalid" ans stuff like that)
2)
I have some files failing when using these optimisations:
c
Hello,
Sorry for typo: both 4.3a and 4.2c are not working.
With studies I have done today it has been broken before 3.6.a
Yes the "do" is with an empty body.
I don't know if it is correct to use empty body the definition is:
do ((variable init step) ...) (test expression ...) body
So for sure,
.. )
I may have more time to submit testcase for other issues in 1 or 2 weeks.
Best Regards,
Pierre
-Original Message-
From: manuel.serr...@inria.fr [mailto:manuel.serr...@inria.fr]
Sent: Wednesday, May 11, 2016 6:36 PM
To: Ollagnon, Pierre-Francois
Cc: bigloo@inria.fr
Subject: Re: [
Hello Guys
1)
We spent a bit of time to work on 3.1b -> 4.3 migration
We succeed to compile when removing all optimization but testcase are hard to
make ...
I face an issue using *fl in the interpreter.
Here is my test (it doesn't do a real thing but shows the error):
(module top
(main
20 matches
Mail list logo
