The .less library calls itself a port of ruby LESS library. Can I take away from that that they both are compilers for the same LESS file format or do they expect subtly different less code? Asked another way, am I locking myself in to the dotless library or can use dotless and the less javascript lib on the less files?
Dotlesscss is a straight (almost 1:1 port) of the JavaScript project less.js (a JavaScript implementation of LessCSS by Cloudhead the original author of LessCss for Ruby)
In 99% of the cases the same code that runs on dotlesscss will run on less.js and vice versa. If something works on less.js and doesn't on dotlesscss we consider that a bug and try to fix it if possible.
There are very subtle differences though as it is very hard to keep three different projects 100% synced up.
For one that would be different function names.
Examples would be the color manipulation functions that we implemented before the LessCss project, as we named these after their SASS equivalents..
But in general: the language though is 100% compatible.
You are not limiting yourself to one language. You should be able to move between different implementations fairly easily.
Also dotless runs on Mono so you are not locked to a specific OS either.
If you encounter any problems feel free to raise an Issue on our GitHub Page or through the Mailing List
They're supposed to be equivalent implemnentations however there is a hudge difference between
the server side implementations (ruby, .net, php ...)
the client side javascript implementation
The big difference is that with the client side implementation, you'll be able to use all the dom of the browser in your less files and this would never work with server side implementations :
#height: `document.body.clientHeight`;
More over, in the current version of dotless (1.2.4.0), javascript evaluation is not implemented and is rendered as [script unsupported] in the css output.
Related
I use Python, but I don't know how it works in Kotlin. This is an example
example => exec("""print("hello")""") output => hello
exec("""print("hello")""") output => hello
Kotlin supports JSR-223. You can use the jvm scripting engine to eval kts files.
val engine = ScriptEngineManager().getEngineByExtension("kts")
engine.eval("""print("hello")""")
You need JSR-223 library dependency. Refer to example
implementation("org.jetbrains.kotlin:kotlin-scripting-jsr223:$kotlinVersion")
Short answer: this isn't practical in Kotlin.
Technically, there may be ways, but they're likely to be far more trouble than they're worth; you're far better looking for a different approach to your problem.
Unlike a dynamic (‘scripting’) language like Python, Kotlin is statically-compiled. In the case of Kotlin/JVM, you run the Kotlin compiler to generate .class files with Java bytecode, which is then run by a JVM.
So if you really need to convert a string into code and run it, you'd have to find a way to ensure that a Kotlin compiler is available on the platform where your code is running (which it often won't be; compiled bytecode can run on any platform with a JVM, and most of those won't have Kotlin installed too). You'd then have to find a way to run the compiler; this will probably mean writing your source code out to a file, starting up the compiler program as a separate process (as I don't think there's an API for calling it directly), and checking the results. Then you'd have find the resulting bytecode and load into the JVM, which will probably mean setting up a separate classloader instance.
All of which is likely to be slow, fragile, and very awkward.
(See these previous questions which cover some of the same ground.)
(The details will be different for Kotlin/JS and Kotlin/Native, but I think the principles are roughly the same.)
In general, each computer language has its own approach, its own mind-set and ways of doing things, and it's best to try to understand that and accept that patterns and techniques from one language don't always translate well into another. (In the Olden Days™, it used to be said that a determined programmer could write FORTRAN programs in any language — but only in satire.)
Perhaps if you could explain why you want to do this, and what sort of problem you're trying to solve (probably as a separate question), we might be able to suggest more natural solutions in Kotlin.
I just converted one of the FsXaml demo programs to an interpreted F# script so I could experiment with it and learn. It wouldn't run, and the interpreter gave me the following error message:
System.NotSupportedException: The invoked member is not supported in a
dynamic assembly.
at System.Reflection.Emit.InternalAssemblyBuilder.GetManifestResourceStream(String
name)
at FsXaml.InjectXaml.from(String file, Object root)
at
FsXaml.App.InitializeComponent() at FsXaml.App..ctor()
at
FSI_0002.main[a](a argv)
in C:\Users\bobmc\OneDrive\FSharp\Learning\WPFExamples\FsXaml\demos\WpfSimpleMvvmApplication\WPFApp.fsx:line 104
at .$FSI_0002.main#() in
C:\Users\bobmc\OneDrive\FSharp\Learning\WPFExamples\FsXaml\demos\WpfSimpleMvvmApplication\WPFApp.fsx:line
109
Can I use the F# interpreter with FsXaml? Thanks to all for your help.
Unfortunately, WPF and scripts don't play well together.
The exception occurs within the WPF runtime itself - FsXaml.InjectXaml is using a XamlObjectWriter to populate the type with the contents from the XAML file. This type doesn't work if you're using a dynamic assembly (like FSI), which unfortunately means that FsXaml will likely never be able to work from FSI.
That being said, even if there was a way around this, it'd be of very limited use. WPF also has restrictions that make it not play well with a scripting scenario, such as the "only one application can ever be created within a given AppDomain" restriction. That one makes it so closing the "main" (first) window makes it so you can never open another one. As such, I haven't prioritized trying to make this work in FSI.
I'd be happy to accept contributions if somebody has an idea of how to make FsXaml play more nicely within the context of FSI, but at this point, I don't see a good solution for that usage scenario.
Edit: FsXaml 3.1.6 now includes functionality to make this a lot easier. It works well, provided you don't close the main window, or you use dialogs. There is a demo application/script illustrating this.
Can I specify a LESS compiler version, that is required to compile the file? E.g. in a comment at the beginning of the file:
// use 1.5.0
I've searched the docs, but it seems like there are no such option.
Basically no, there's no such option. And even if it's added in future LESS versions, an older versions still won't have it so this does not help too much soon. Besides older less.js versions, there're a few LESS ports which are also a bit behind the official implementation so you never know what happens with your LESS sources when you give it away.
(Not mentioning that each LESS compiler also usually has several options that affect CSS output, e.g.: --strict-math).
Well, there's possibility to put a sort of version guard into your code, for example once I tried something like this:
.version-guard__() when not(length(-) = 1) {
-:##-;#-:': requires LESS version 1.5.0 or higher';
} .version-guard__();
But it works in less.js only, and it's not so easy to craft an universal trick that will work with other LESS implementations since each one handles errors in slightly different ways (though, to be honest, I did not bother with that too much since my main goal was to get a reasonable error message).
P.S. Alternative version guard method:
.version-guard__ {
-+: requires LESS version 1.5.0 or higher;
}
This one works in less.js and lessphp (at least) but generates dummy CSS output (unlike the first one).
Can I have an application that is based on flex4 SDK and a library (swc file) inside this project which is based on another version of flex (3.2)?
how will flex deal with this situation?
In theory, a Flex 3 SWC should work fine for all Flex 3 point releases. A Flex 4 SWC should work fine with all Flex 4 point releases. I wouldn't expect a Flex 3 SWC to work against Flex 4, but it depends what is in the SWC and what classes are used.
In practice, odd errors sometimes do crop up. I strongly recommend compiling all your SWCs against the same SDK you use with your main project. A lot of odd runtime and compiler errors can be solved by making sure your versions match.
This is the type of question that makes me wonder "wouldn't it have been quicker to try it than to ask the question." Are you having a specific problem?
Think of it this way:
Your Flex application starts loading and flashPlayer loads in the UIComponent class. When the classes from your swc are used (and they have a UIComponent compiled-in from Flex 3.2) flashPlayer uses the already-used UIComponent from the swf that was first initializing, not the one that was compiled into the swc.
[well, that's simplified -- it's the compiler that does all this crap to cut-down on swf size... modules do the same thing tho'. read up on applicationDomain stuff across modules -- if two modules use the same class and one is loaded first, the second (even if it has the updated version of that class) will use the old, first-loaded class.]
Best practice: don't use swcs. If possible, build from the source with the exact same sdk used for compiling.
Next-best practice: Use swcs that don't use many Flex classes. Swiz is a great example.... they pull in some flex classes, but if you search on the project for "mx." you'll find 25ish results of classes that won't change any time soon --- IMXMLObject, FlexEvent and some Binding classes. If your swc uses ComboBox, you are in trouble, period. (have you seen bug releases for ComboBox in the last two years? -- that thing has changed more times since the 3.2sdk than the times I've changed clothes, and that's at least once per week).
I don't spend a lot of time on this site, but I'd be interested in knowing which swc you're trying to pull in. Is it open-source?
I hope that helps.
Best of luck,
Jeremy
this is my first post, and it covers something which I've been trying to get working on and off for about a year now.
Essentially it boils down to the following: I have a copy of newlib which I'm trying to get working on an LPC2388 (an ARM7TDMI from NXP). This is on a linux box using arm-elf-gcc
The question I have is that I've been looking at a lot of the tutorials talking about porting newlib, and they all talk about the stubs (like exit, open, read/write, sbrk), and I have a pretty good idea of how to implement all of these functions. But where should I put them?
I have the newlib distribution from sources.redhat.com/pub/newlib/newlib-1.18.0.tar.gz and after poking around I found "syscalls.c" (in newlib-1.18.0/newlib/libc/sys/arm) which contains all of the stubs which I have to update, but they're all filled in with rather finished looking code (which does NOT seem to work without the crt0.S, which itself does not work with my chip).
Should I just be wiping out those functions myself, and re-writing them? Or should I write them somewhere else. Should I make a whole new folder in newlib/libc/sys with the name of my "architecture" and change the target to match?
I'm also curious if there's proper etiquette on distribution of something like this after releasing it as an open source project. I currently have a script which downloads binutils, arm-elf-gcc, newlib, and gdb, and compiles them. If I am modifying files which are in the newlib directory, should I hand a patch which my script auto-applies? Or should I add the modified newlib to the repository?
Thanks for bothering to read! Following this is a more detailed breakdown of what I'm doing.
For those who want/need more info about my setup:
I'm building a ARM videogame console based loosely on the Uzebox project ( http://belogic.com/uzebox/ ).
I've been doing all sorts of things pulling from a lot of different resources as I try and figure it out. You can read about the start of my adventures here (sparkfun forums, no one responds as I figure it out on my own): forum.sparkfun.com/viewtopic.php?f=11&t=22072
I followed all of this by reading through the Stackoverflow questions about porting newlib and saw a few of the different tutorials (like wiki.osdev.org/Porting_Newlib ) but they also suffer from telling me to implements stubs without mentioning where, who, what, when, or how!
But where should I put them?
You can put them where you like, so long as they exist in the final link. You might incorporate them in the libc library itself, or you might keep that generic, and have the syscalls as a separate target specific object file or library.
You may need to create your own target specific crt0.s and assemble and link it for your target.
A good tutorial by Miro Samek of Quantum Leaps on getting GNU/ARM development up and running is available here. The examples are based on an Atmel AT91 part so you will need to know a little about your NXP device to adapt the start-up code.
A ready made Newlib porting layer for LPC2xxx was available here, but the links ot teh files appear to be broken. The same porting layer is used in Martin Thomas' WinARM project. This is a Windows port of GNU ARM GCC, but the examples included in it are target specific not host specific.
You should only need to modify the porting layer on Newlib, and since it is target and application specific, you need not (in fact probably should not) submit your code to the project.
When I was using newlib that is exactly what I did, blew away crt0.s, syscalls.c and libcfunc.c. My personal preference was to link in the replacement for crt0.s and syscalls.c (rolled the few functions in libcfunc into the syscalls.c replacement) based on the embedded application.
I never had an interest in pushing any of that work back into the distro, so cannot help you there.
You are on the right path though, crt0.S and syscalls.c are where you want to work to customize for your target. Personally I was interested in a C library (and printf) and would primarily neuter all of the functions to return 0 or 1 or whatever it took to get the function to just work and not get in the way of linking, periodically making the file I/O functions operate on linked in data in rom/ram. Basically without replacing or modifying any other files in newlib I had a fair amount of success, so you are on the right path.