search for: myoptions

...<- match.arg(arg3) result <- arg1 + arg2 cat(arg3, result, '\n') } myFunction2 <- function(arg1, arg2){ result <- arg1 * arg2 result } ### Working Example. ### myFunction2 works no problem myFunction2Vals <- subset(scoreConfig, Function == 'myFunction2') myOptions <- with(myFunction2Vals, paste(Argument, Value, sep = '=', collapse = ',')) eval(parse(text = paste( "myFunction2(", myOptions, ")" ))) ### myFunction1 fails myFunction1Vals <- subset(scoreConfig, Function == 'myFunction1') myOptions <- with(m...

...-5,7 +5,12 @@ init: function(element, api){ var me = this; if ( google && google.maps ){ - var map = new google.maps.Map(element, {mapTypeId:google.maps.MapTypeId.ROADMAP}); + // be default no controls and road map + var myOptions = { + disableDefaultUI: true, + mapTypeId: google.maps.MapTypeId.ROADMAP + }; + var map = new google.maps.Map(element, myOptions); // deal with click @@ -28,8 +33,15 @@ }, applyOptions: function(){ - var map = this.ma...

...} > > > myFunction2 <- function(arg1, arg2){ > result <- arg1 * arg2 > result > } > > > ### Working Example. > ### myFunction2 works no problem > myFunction2Vals <- subset(scoreConfig, Function == 'myFunction2') > myOptions <- with(myFunction2Vals, paste(Argument, Value, sep = '=', collapse = ',')) > eval(parse(text = paste( "myFunction2(", myOptions, ")" ))) > > > ### myFunction1 fails > myFunction1Vals <- subset(scoreConfig, Function == 'myFunction1')...

Hey Andy > One easy pattern to follow is to register the option during pass initialization with all the convenient flags and parameters, but refer to a globally defined option storage that enforces the singleton and provides visibility. As long as pass initialization happens before parseCommandLine, usage should be consistent. > > Strawman: > > cl::optval<bool> MyOption; //

LLVM's internal command line library needs to evolve. We have an immediate need to build LLVM as a library free of static initializers, but before brute-force fixing this problem, I'd like outline the incremental steps that will lead to a desirable long term solution. We want infrastructure in place to provide an evolutionary path. In the near term, clients who need llvm-the-library with

Thank you all for your suggestions! @David, thanks for the advice, I'll check MCOptions again and look into LLVMContext. @Craig, @Aaron, great suggestion, moving the option away from CommandFlags.inc to a more appropriate file and adding an extern declaration to the corresponding header gives me more flexibility and allows me to invoke the option by using -mllvm. From my current

...; - + if (args.zoom == ''large''){ + this.addLargeControls(); + } else { + this.addSmallControls(); + } } }, @@ -66,7 +68,7 @@ var map = this.maps[this.api]; var myOptions = { navigationControl:true, - navigationControlOptions: {style:google.maps.NavigationControlStyle.DEFAULT}, + navigationControlOptions: {style:google.maps.NavigationControlStyle.DEFAULT} }; map.setOptions(myOptions); this.addControls...

Hello, I am using lpxelinux.0 (latest stable version 6.03, using the official binaries from kernel.org) to kickstart servers as http transfers really helps over links with poor latencies... These servers are being booted in legacy mode, not in UEFI. This has worked very well until recently. Starting with RHEL 7.5, on some servers, we would see the machine rebooting while pxelinux is in the

...t" src="http://maps.google.com/maps/api/js? sensor=false"></script> <script type="text/javascript"> function initialize() { var latlng = new google.maps.LatLng(28.142722, -15.448609); //Creatin a MapOptions object with tthe required properties var myOptions = { zoom: 3, center: latlng, mapTypeId: google.maps.MapTypeId.ROADMAP }; //Creating the map var map = new google.maps.Map(document.getElementById("mapilla"), myOptions); // add the marker itself var marker = new google.maps.Marker({ position: lat...

...S stack somewhere? Just some random and humble thoughts... Perhaps it would be worth some additional tests? Maybe a test with pxelinux.0 version 4.07? And using "LINUX", not "KERNEL": ### DEFAULT biginitrd PROMPT 0 LABEL biginitrd LINUX mykernel INITRD mybiginitrd APPEND myoptions ### Maybe a packet capture might reveal something about the network setup? Maybe it is not the size of the initrd file but rather a time limitation (which gets triggered by a big-enough file)? What about trying with 6.04-pre1, and/or (even better) with Debian Sid's packages and using debug...

Wait, I have a terrible idea. Why don't we roll our own .init_array style appending section? I think we can make this work for all toolchains we support. We'd have something like: struct PODOptData { const char *FlagName; ... // Common POD stuff, can be initialized at ParseCommandLine time. }; LLVM_SECTION(".llvmopt") PODOptData OptionRegisterer = { "foo_flag",

Hi Scott, On 11/05/13 00:09, Scott Pakin wrote: > Is it possible for a pass to get access to the command line options > passed to it? That is, if I use the CommandLine library to define > > cl::opt<int> Foo("foo", ...); > cl::opt<int> Bar("bar", ...); > cl::opt<bool> Baz("baz", ...); > > and the user runs

...not just lpxelinux.0. Alternatively (and in many cases, even better) you could try current Debian's "Unstable" packages, which are "more up-to-date" than 6.04-pre1. B_ In the configuration file, instead of using: ### LABEL mylabel KERNEL mykernel INITRD myinitrd APPEND myoptions ### try: ### LABEL mylabel LINUX mykernel INITRD myinitrd APPEND myoptions ### and/or also try: ### LABEL mylabel2 COM32 linux.c32 APPEND initrd=myinitrd myoptions ### (Reminder: use linux.c32 and the lib*.c32 modules from the same version as lpxelinux.0 and ldlinux.c32.) Using the LINUX d...

CommandFlags.inc is only included by llc and opt. I think it mostly just sets things on TargetMachine and TargetOptions and connects them to command line options. Clang has its own code for setting up TargetMachine and TargetOptions. I think a lot of configuration things these days tend to be done with function attributes in IR. You can just query the function attribute wherever without any need

Isnt all the command line options only relevant to the driver, so if all the command line options are migrated to the driver, the library will be free from static initializers. Doesnt this make it more cleaner ? Thanks Shankar Easwaran On 9/17/2013 12:10 PM, Andrew Trick wrote: > LLVM's internal command line library needs to evolve. We have an immediate need to build LLVM as a library

Is it possible for a pass to get access to the command line options passed to it? That is, if I use the CommandLine library to define cl::opt<int> Foo("foo", ...); cl::opt<int> Bar("bar", ...); cl::opt<bool> Baz("baz", ...); and the user runs "opt -load mypass.so -foo=123 -std-compile-opts -baz", can I somehow get a string

On Sep 17, 2013, at 10:31 AM, Eric Christopher <echristo at gmail.com> wrote: > Hi Andy, > > I definitely agree with the desire to remove command line options and > having them be initialized as part of the pass would be general > goodness. However, a few possible issues: > > a) a number of command line options aren't really connected to passes > per-se

----- Original Message ----- > LLVM's internal command line library needs to evolve. We have an > immediate need to build LLVM as a library free of static > initializers, but before brute-force fixing this problem, I'd like > outline the incremental steps that will lead to a desirable long > term solution. We want infrastructure in place to provide an > evolutionary path.

Hi Andy, I definitely agree with the desire to remove command line options and having them be initialized as part of the pass would be general goodness. However, a few possible issues: a) a number of command line options aren't really connected to passes per-se (backend options) b) "As long as pass initialization happens before parseCommandLine, usage should be consistent." I'm

On Sep 17, 2013, at 11:25 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Isnt all the command line options only relevant to the driver, so if all the command line options are migrated to the driver, the library will be free from static initializers. > > Doesnt this make it more cleaner ? Yes, but less convenient for developing experimental passes. I think we want to