similar to: x86 vs. x86_64 detection proof of concept patch

Greetings all, Sorry, resending this with the attachment inline. First of all, a disclaimer: Please forgive my horrible assembly code. This is just a quick munging of code to achieve x86 versus x86_64 detection within pxelinux. So please look at it as a proof of concept and not a real piece of code. :) For example it only works on pxelinux and has no thought for extending it beyond simple x86

Hi all, I know, its normally a sendmail question (sendmail mailing list). But I don't want to subscribe me for this only one question. I hope, here are also many sendmail freaks ;-) many Thanks. Now my problem. We are running sendmail-8.13.8-8.el5 on a CentOS release 5.5 (Final) Box. We have to setup relaying for a person, which is connected to the internet with a dailup connection. So

Dear all, I'm trying to produce a log-likelihood profile for a GPD estimate with the ismev package. When following the examples, everything is working fine, i.e. I get a nice parabolic log-likelihood curve. When using my own data (intensity of hurricanes at landfall), the log-likelihood curve looks like a step function. Am I doing something wrong here? Is my data not suited for the GPD fit?

Hi Helpers: I have a factor object that has 314k entries of 39 land cover types. (This object can be coerced to characters neatly should that be easier to work with.) > length(foo) [1] 314482 > foo[1:10] [1] Montane Chaparral Barren Red Fir Red Fir [5] Red Fir Red Fir Red Fir Red Fir [9] Red Fir Red Fir 39 Levels:

2010/10/21 Jason Kim <jasonwkim at google.com>: > Of the 45 remaining, there are 4 interesting uses in MCAsmStreamer.cpp > - (I suppose for emitting data constants in a cross platform manner) > The other remaining uses are in AsmPrinter, again to do cross platform things. > It seems a bit strange to use a high level hammer to do ballpeen > work..... But when in Rome.... :-)

OK, after reading the docs I have some extra comments (and an updated patch). *) To support per section or per symbol attributes we would have to move this to the processing done in the end of the file. Lets not do this right now. *) We don't currently use any string attributes, so I did not implement them. *) Having an attribute emitter class is a nice way to separate the job of creating the

I also noticed that we were trying to optimize the output of 41 bytes of data :-) The attached patch is similar to the previous one but drops the API changes by just accumulating the attributes locally before outputting them. Cheers, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: attrs.patch Type: text/x-patch Size: 12333 bytes Desc: not available URL:

I work for a multi-billion dollar international organization currently using Novell technology for F&P/Directory/etc... A project has just arisen to develop several potential replacement proofs of concept. Several solutions are being evaluated, including: * Microsoft CIFS * Some NAS device using AD or eDirectory * Linux/Samba I was chosen as part of the Linux/Samba team and I'd like to

On May 6, 2008, at 14:20, Frederick Akalin wrote: > On Tue, May 6, 2008 at 2:03 PM, Brian Willoughby > <brianw at sounds.wa.com> wrote: >> 3) Do you accelerate decode as well as encode? I'm thinking that >> the >> variable block size would require each thread to scan its block >> for the >> start of a new block header, and also continue

Hey again FLAC devs, I managed to hack out another proof-of-concept multithreaded FLAC encoder that is more amenable to streaming and also uses a fixed buffer size. The performance is pretty much the same as my earlier version; that is, I can encode a 636 MB wave file in ~7s with 8 threads on an 8-core 2.8 GHz Xeon (I erroneously stated 3.0 GHz in my last e-mail) vs ~32s with 1 thread. I had

Honestly, I don't see the motivation for this. There are many similar projects that are mature, so my feedback would be: don't reinvent the wheel and contribute to those. I?aki El vie., 14 jun. 2019 3:18, Abby Spurdle <spurdle.a at gmail.com> escribi?: > I thought that I'd get more feedback. > But it's ok, I understand. > > I wanted to note that I've moved

On Fri, Jun 14, 2019 at 7:24 PM I?aki Ucar <iucar at fedoraproject.org> wrote: > > There are many similar projects that are mature I'm not sure what projects you're referring to. If we create some constraints: (1) Internal systems consoles (*plural*). Rules out most things. Noting that many tools are designed to bypass the console. (2) Modern user interface. Rules out Vim

2010/10/21 Jason Kim <jasonwkim at google.com>: > That is exactly what I need - I need a nice MC way to output a at > least two different 4 byte size fields after all of the blobs in the > .ARM.attributes are sent out. Hi Jason, If I got it right, you need to write to the attributes section after you have moved out to print the rest of the file. I can't think of an example

On Sat, 15 Jun 2019 at 01:24, Abby Spurdle <spurdle.a at gmail.com> wrote: > > None of the tools that I've looked at satisfy these constraints. > But if you know of some, I'd like to know... And I would consider contributing... What about Atom, VS Code and the like? Or what about taking a project that meets most of the constraints and pushing to cover all of them, or even

On Thu, Oct 21, 2010 at 11:42 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Also what is the preferred method for MC way of setting out subsection >> sizes after the fact? I am guessing I need to use an MCFixup? >> How do I get an MCExpr to evaluate a method for the subsection size? >> Is there an equivalent use in the places using MCFixup? >>

After upgrading to centos 5.4 I am getting a selinux violation, yet nothing is logged to /var/log/audit/audit.log. Other violations do get logged. The violation occurs when running the following command on the mail server: aspen> /usr/bin/Mail centos at centos.org Subject: test hi Cc: aspen> send-mail: warning: premature end-of-input on /usr/sbin/postdrop -r while reading input

Frederick, This is great news! Thanks for your effort. Your proof-of-concept raises a few questions for me: 1) I know that the ratio of uncompressed to compressed data is unpredictable, but I never really considered whether the input block size or the output block size is constant. I'm assuming that if you're breaking the uncompressed input file into multiple pieces, then the

I've written what I refer to as an "Integrated Console Environment". Similar to an IDE, but more console oriented, so suitable for running scripts and dynamic programming languages. Also, it's designed to be congruent with the file system. Obviously, I want to support R. However, the long term plan is to make the core system relatively language neutral, and to support R via a

---------- Forwarded message ---------- From: Jason Kim <jasonwkim at google.com> Date: Fri, Oct 22, 2010 at 12:59 PM Subject: Re: [llvm-commits] Fwd: Proof of concept patch for unifying the .s/ELF emission of .ARM.attributes To: Rafael Espíndola <rafael.espindola at gmail.com> On Fri, Oct 22, 2010 at 12:51 PM, Jason Kim <jasonwkim at google.com> wrote: > On Thu, Oct 21,

On Wed, Oct 20, 2010 at 2:56 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Gosh, this is taking a while :-) >> Is there anything else I missed? > > Another one I noticed. Instead of > >      SmallString<32> *FC = &currFileFragment.getContents(); >      (*FC) += static_cast<char>(attr); >      (*FC) += static_cast<char>(0xFF