search for: ghostwheel

...''m affraid shorewall is not the one to blame. First of all I''m using shorewall version 2.0.15 on two linux box. I set up an ipsec tunnel beetween those 2 boxes to be ables to connect 2 not routable subnetworks. Here is my network topology: 10.66.17.0/24 - 10.66.17.1 = eth0 ghostwheel eth1 = ip1 < Internet > ip2 = eth1 marelle eth0 = 10.66.42.1 - 10.66.42.0/24 And you have logrus with the ip 10.66.42.2. From ghostwheel, I can ping ip2 and 10.66.42.1. But when I ping 10.66.42.2, here what I see on marelle: marelle ~ $ sudo tcpdump -l -i eth1 | grep icmp tcpdump: ver...

Hi, I have a few problems with my shorewall configuration. First of all, the option maclist seems no to be recognized. I have this: ghostwheel /etc/shorewall # cat interfaces | grep -v ''^#'' - eth1 detect dhcp,tcpflags,routefilter loc eth0 detect tcpflags,maclist When I look at shorewall-init.log, I found out: ghostwheel /etc/shorewall # grep MAC /var/log/shorewall-in...

...gt; user 5m12.612s > sys 1m1.205s > > why is lli taking such a loooong time to execute this particular piece of code.?? Something's wrong on your machine or something. I did the same (but using llvm-gcc for the .ll files). Using a debug build of current ToT I got this: [ghostwheel:~/Desktop] echristo% time ~/builds/build-llvm-64bit/Debug/bin/lli foo.bc.bc 0.210u 0.010s 0:00.22 100.0% 0+0k 0+0io 0pf+0w That's a 64-bit build, but you'll notice the time difference. That said I'm guessing that there's something missing since it takes no time to execute. Step by...

...gt;> >> why is lli taking such a loooong time to execute this particular >> piece of code.?? > > Something's wrong on your machine or something. I did the same (but > using llvm-gcc for the .ll files). Using a debug build of current > ToT I got this: > > [ghostwheel:~/Desktop] echristo% time ~/builds/build-llvm-64bit/ > Debug/bin/lli foo.bc.bc > 0.210u 0.010s 0:00.22 100.0% 0+0k 0+0io 0pf+0w > > > That's a 64-bit build, but you'll notice the time difference. That > said I'm guessing that there's something missing since i...

...to execute this particular piece >>>> of code.?? >>>> >>> >>> Something's wrong on your machine or something. I did the same (but using >>> llvm-gcc for the .ll files). Using a debug build of current ToT I got this: >>> >>> [ghostwheel:~/Desktop] echristo% time >>> ~/builds/build-llvm-64bit/Debug/bin/lli foo.bc.bc >>> 0.210u 0.010s 0:00.22 100.0% 0+0k 0+0io 0pf+0w >>> >>> >>> That's a 64-bit build, but you'll notice the time difference. That said >>> I'm guessin...

...i taking such a loooong time to execute this particular piece of >>> code.?? >>> >> >> Something's wrong on your machine or something. I did the same (but using >> llvm-gcc for the .ll files). Using a debug build of current ToT I got this: >> >> [ghostwheel:~/Desktop] echristo% time >> ~/builds/build-llvm-64bit/Debug/bin/lli foo.bc.bc >> 0.210u 0.010s 0:00.22 100.0% 0+0k 0+0io 0pf+0w >> >> >> That's a 64-bit build, but you'll notice the time difference. That said >> I'm guessing that there's somet...

After LLVM rev 84987, the RaiseAllocations pass no longer exists. llvm-gcc needs to be patched: Index: gcc/llvm-linker-hack.cpp =================================================================== --- gcc/llvm-linker-hack.cpp (revision 84984) +++ gcc/llvm-linker-hack.cpp (working copy) @@ -80,7 +80,6 @@ llvm::createJumpThreadingPass(); llvm::createFunctionInliningPass();

Hi, I have my data in below format. position var1 var2 2 .1 10 3 .29 89 12 .56 100 425 .34 1234 6546 .12 21 .... ..... ..... .... ..... ......

I wrote the interface between R and TeXmacs. Recently, I added tab completion. However, there is one slight problem. In order to enable easy interaction with R, I (I.e. my program) interact with the command-line interface. This means that the user can invoke demo(), and then R will interact with the user and ask to press enter. It also means that the user can enter a<-c(3,4 and then R will

Another message about the R to TeXmacs interface. 1. Graphics The TeXmacs interface allows the user to directly insert graphics into the session. Since I am not very familiar with programming for R, I implemented the interaction with graphics in a very primitive way. It was two modes of working: with X11, and without (for example when working remotely through ssh without forwarding X11). In

I'm not sure if this is a known peculiarity or a bug, but I stumbled across what I think is very odd behavior from delayedAssign. In the below example x switches values the first two times it is evaluated. > delayedAssign("x", {x <- 2; x+3}) > x==x [1] FALSE > delayedAssign("x", {x <- 2; x+3}) > x [1] 5 > x [1] 2 The ?delayedAssign documentation says

Hi all, I am trying to compare the performance of gcc , llvm-gcc , clang and lli(with JIT) on x86. i have attached the performance comparision spreadsheet as well as the source which i used for performing these test. i ran this code for 10000 iterations and the time of execution is as follows for -O3 results refer attachment. *time clang (-O0) llvm-gcc(-O0)

Hi all, I am trying to compare the performance of gcc , llvm-gcc , clang and lli(with JIT) on x86. i have attached the performance comparision spreadsheet as well as the source which i used for performing these test. i ran this code for 10000 iterations and the time of execution is as follows for -O3 results refer attachment. *clang (-O0) * real 0m10.247s user 0m2.644s sys 0m5.949s