What does "forceCompile" mean on YII when you use Less? - yii

I have this:
'components'=>array(
'less'=>array(
'class'=>'ext.less.components.LessCompiler',
'forceCompile'=> true, //YII_DEBUG, // indicates whether to force compiling
//'compress'=>false, // indicates whether to compress compiled CSS
//'debug'=>false, // indicates whether to enable compiler debugging mode
'paths'=>array(
'less/style.less'=>'css/style.css',
),
),
If I enable forceCompile my site is extremely slow. I would imagine because it regenerates the css on each page load. My question is around disabling it. If I disable it:
Will any changes I make to style.less not reflect in the browser?
If so, what is the point of Less? Surely it can't actually be used in production then? Or do you disable forceCompile so it only generates it once?
Any clarity on forceCompile would be highly appreciated!
(And yes, I looked all of for a clear explanation... best I could find was this).

First let me tell you what is the point of less:
less is a meta language, so in general terms using less helps you write easily maintainable css, although the "language" used is less syntax. As a common example, you can define variables in less that are compiled to css values according to the other statements in your less file. Or you can use mixins, nesting, inheritance concepts like you would in most other languages that support OOP.
So you write understandable, readable pseudo/meta css code that is converted to actual css upon compilation.
Now the extension:
Even if you disable forceCompile, the changes made in style.less should reflect, because the extension checks if the file was modified (the following lines from LessCompiler.php should convince you about that):
if ($this->forceCompile || $this->hasChanges())
$this->compileAll();
// ...
/**
* Returns whether any of files configured to be compiled has changed.
* #return boolean the result.
*/
protected function hasChanges() {
// ...
$compiled = $this->getLastModified($destination);
// ...
$modified = $this->getLastModified($dir);
// ...
}
/**
* Returns the last modified for a specific path.
* #param string $path the path.
* #return integer the last modified (as a timestamp).
*/
protected function getLastModified($path){
//...
}
So forceCompile will always compile the file(s) you specify in paths, and you should not enable it in production. The hasChanges call should take care of less files that have been modified, and compile them, which as you see above is automatically done by the extension.

Related

(How) can a VS Code extension access [language]-specific `settings.json` sub-section values?

Example: extension code can very trivially determine the value of editor.formatOnSave. But from what I can tell and have tried, it seems nigh impossible to query the current document/editor whether that setting is effective right there, right now. With [language]-specific sub-sections it may be enabled for Go but disabled for others for example --- or vice versa. And "some" (ie. mine) extension might "need" (ie. want) to know about it!
If you try to use the documented getConfiguration("language").get("setting") it won't work. But there is a workaround to access what you want.
Let's suppose you want to load editor.formatOnSave for markdown files. If you look at User Settings, you will see it stored like this:
["markdown"]: {
"editor.wordWrap": "wordWrapColumn",
"editor.formatOnSave": true
}
You just have to load the configuration object and access the desired properties, like this:
let markdownObject = vscode.workspace.getConfiguration("[markdown]");
if (markdownObject["editor.formatOnSave"]) {
console.log("[markdown].editor.formatOnSave is TRUE");
}
It's important to note that you must use [markdown] (between brackets) because that is how it is represented on the JSON file.
Also note that this workaround will not give you access to settings that are not overridden for languages. In that case, you must use/combine the documented API.

How to make PHPStorm treat a function as defined?

The double_metaphone() function is defined in a PECL extension and as such PHPStorm cannot see it being defined. I wouldn't like to see any warnings about this. I assume I could make PHPStorm treat this function call as defined through some kind of annotation but I don't know how to make this happen.
You need what is called "stub files":
Create a .php file and place it anywhere in your project (be it project itself... or as an External Library (Settings | PHP | Include paths) -- it does not matter, as long as PhpStorm can see it in this project).
Add that function definition as it would be done in PHP itself: describe all parameters, return type etc. and just leave the body of the function empty.
The documentation is optional: it's just the more doc you have the more useful it will be for PhpStorm and you: the IDE can warn you about invalid parameter type, incorrect return type usage, suggest variables of appropriate types when using code completion for that function etc.
That's it
That's exactly how ALL known PHP functions/classes/etc are done in PhpStorm in the first place: just Ctrl + Click on any standard function/class/constant and see it yourself.
An example: how standard bin2hex function is defined (back in 2013):
<?php
/**
* (PHP 4, PHP 5)<br/>
* Convert binary data into hexadecimal representation
* #link http://php.net/manual/en/function.bin2hex.php
*
* #param string $str A character.
* #return string the hexadecimal representation of the given string.
*/
function bin2hex ($str) {}
You can see all current PhpStorm stubs (and other helper files that IDE uses for PHP completion) in this official repo: https://github.com/JetBrains/phpstorm-stubs

configuration file of consts to many classes

Using objective c , I have 2 classes that are using hardware, and are written in c +objC .
The other classes in the project are objective c, and they create instance of those classes.
My question .
Lets say I have classA.m and classB.m . they both have an integer const that needs to be the same say : const int numOfSamples=7;
I am seeking for the best solution to create some configuration file, that will holds all this const variables, that both A and B can see them .
I know some ways,but I wonder whats the RIGHT thing to do .
I wonder if I can just create a : configuration.m and write them into it .
to use a singleton file that holds all globals .
Number 1 seems to me the best , but how exactly should I do it ?
Thanks.
For approach 1 to work, you need to define two files:
a header file where you declare all of your constants;
a .m file where your constants are defined and initialized.
In your example:
/* .h file */
extern const int numOfSamples;
/* .m or .c file */
const int numOfSamples = 7;
Then, you include the .h header in every other file where you need those constants. Notice the extern keyword, this will declare the variable without also defining; in this way, you can include the .h file multiple times without having a duplicate symbol error.
EDIT:
The approach I suggest is the correct way to handle global variables in a C program.
Now, if global variables are a good thing or not, well, that is a longer story.
Generally speaking, global variables are tricky and go against a 40 years long effort towards better encapsulation (aka, information hiding) of data and behavior in a program (see "On the Criteria to Be Used in Decomposing Systems Into Modules", David Parnas, 1972).
To further explain this, one aspect of the problem is exactly what you mention in your comment: the possibility of one module changing the value of a global variable and thus affecting the whole behavior of the program. This is recognizedly bad and leads to uncontrollable side effects (in any non trivially sized program).
In your case, I think things are a bit different, in that you are talking about "configuration" and "const" values. This is an altogether different case than the general one and I think you could safely use a header file of consts to that aim.
That said, you understand that the whole theme of configuration is a huge one, in general. E.g., you could need mechanisms to change your program configuration on the fly; in this case the constant variable header approach would be not correct. Or, your program configuration could depend on the state of some remote system (imagine: you are logged in vs. you are not logged in).
I can't guarantee that using a header file is the best approach for your case, but I hope that the above discussion and the example I gave you can help you figure that out.
I think the best way is to use a plist file with all your configuration values.
If you have few configuration values, you can use the Info.plist file.

Description format for an embedded structure

I have a C structure that allow users to configure options in an embedded system. Currently the GUI we use for this is custom written for every different version of this configuration structure. What I'd like for is to be able to describe the structure members in some format that can be read by the client configuration application, making it universal across all of our systems.
I've experimented with describing the structure in XML and having the client read the file; this works in most cases except those where some of the fields have inter-dependencies. So the format that I use needs to have a way to specify these; for instance, member A must always be less than or equal to half of member B.
Thanks in advance for your thoughts and suggestions.
EDIT:
After reading the first reply I realized that my question is indeed a little too vague, so here's another attempt:
The embedded system needs to have access to the data as a C struct, running any other language on the processor is not an option. Basically, all I need is a way to define metadata with the structure, this metadata will be downloaded onto flash along with firmware. The client configuration utility will then read the metadata file over RS-232, CAN etc. and populate a window (a tree-view) that the user can then use to edit options.
The XML file that I mentioned tinkering with was doing exactly that, it contained the structure member name, data type, number of elements etc. The location of the member within the XML file implicitly defined its position in the C struct. This file resides on flash and is read by the configuration program; the only thing lacking is a way to define dependencies between structure fields.
The code is generated automatically using MATLAB / Simulink so I do have access to a scripting language to help with the structure creation. For example, if I do end up using XML the structure will only be defined in the XML format and I'll use a script to create the C structure during code generation.
Hope this is clearer.
For the simple case where there is either no relationship or a relationship with a single other field, you could add two fields to the structure: the "other" field number and a pointer to a function that compares the two. Then you'd need to create functions that compared two values and return true or false depending upon whether or not the relationship is met. Well, guess you'd need to create two functions that tested the relationship and the inverse of the relationship (i.e. if field 1 needs to be greater than field 2, then field 2 needs to be less than or equal to field 1). If you need to place more than one restriction on the range, you can store a pointer to a list of function/field pairs.
An alternative is to create a validation function for every field and call it when the field is changed. Obviously this function could be as complex as you wanted but might require more hand coding.
In theory you could generate the validation functions for either of the above techniques from the XML description that you described.
I would have expected you to get some answers by now, but let me see what I can do.
Your question is a bit vague, but it sounds like you want one of
Code generation
An embedded extension language
A hand coded run-time mini language
Code Generation
You say that you are currently hand tooling the configuration code each time you change this. I'm willing to bet that this is a highly repetitive task, so there is no reason that you can't write program to do it for you. Your generator should consume some domain specific language and emit c code and header files which you subsequently build into you application. An example of what I'm talking about here would be GNU gengetopt. There is nothing wrong with the idea of using xml for the input language.
Advantages:
the resulting code can be both fast and compact
there is no need for an interpreter running on the target platform
Disadvantages:
you have to write the generator
changing things requires a recompile
Extension Language
Tcl, python and other languages work well in conjunction with c code, and will allow you to specify the configuration behavior in a dynamic language rather than mucking around with c typing and strings and and and...
Advantages:
dynamic language probably means the configuration code is simpler
change configuration options without recompiling
Disadvantages:
you need the dynamic language running on the target platform
Mini language
You could write your own embedded mini-language.
Advantages:
No need to recompile
Because you write it it will run on your target
Disadvantages:
You have to write it yourself
How much does the struct change from version to version? When I did this kind of thing I hardcoded it into the PC app, which then worked out what the packet meant from the firmware version - but the only changes were usually an extra field added onto the end every couple of months.
I suppose I would use something like the following if I wanted to go down the metadata route.
typedef struct
{
unsigned char field1;
unsigned short field2;
unsigned char a_string[4];
} data;
typedef struct
{
unsigned char name[16];
unsigned char type;
unsigned char min;
unsigned char max;
} field_info;
field_info fields[3];
void init_meta(void)
{
strcpy(fields[0].name, "field1");
fields[0].type = TYPE_UCHAR;
fields[0].min = 1;
fields[0].max = 250;
strcpy(fields[1].name, "field2");
fields[1].type = TYPE_USHORT;
fields[1].min = 0;
fields[1].max = 0xffff;
strcpy(fields[2].name, "a_string");
fields[2].type = TYPE_STRING;
fields[2].min = 0 // n/a
fields[2].max = 0 // n/a
}
void send_meta(void)
{
rs232_packet packet;
memcpy(packet.payload, fields, sizeof(fields));
packet.length = sizeof(fields);
send_packet(packet);
}

Write a compiler for a language that looks ahead and multiple files?

In my language I can use a class variable in my method when the definition appears below the method. It can also call methods below my method and etc. There are no 'headers'. Take this C# example.
class A
{
public void callMethods() { print(); B b; b.notYetSeen();
public void print() { Console.Write("v = {0}", v); }
int v=9;
}
class B
{
public void notYetSeen() { Console.Write("notYetSeen()\n"); }
}
How should I compile that? what i was thinking is:
pass1: convert everything to an AST
pass2: go through all classes and build a list of define classes/variable/etc
pass3: go through code and check if there's any errors such as undefined variable, wrong use etc and create my output
But it seems like for this to work I have to do pass 1 and 2 for ALL files before doing pass3. Also it feels like a lot of work to do until I find a syntax error (other than the obvious that can be done at parse time such as forgetting to close a brace or writing 0xLETTERS instead of a hex value). My gut says there is some other way.
Note: I am using bison/flex to generate my compiler.
My understanding of languages that handle forward references is that they typically just use the first pass to build a list of valid names. Something along the lines of just putting an entry in a table (without filling out the definition) so you have something to point to later when you do your real pass to generate the definitions.
If you try to actually build full definitions as you go, you would end up having to rescan repatedly, each time saving any references to undefined things until the next pass. Even that would fail if there are circular references.
I would go through on pass one and collect all of your class/method/field names and types, ignoring the method bodies. Then in pass two check the method bodies only.
I don't know that there can be any other way than traversing all the files in the source.
I think that you can get it down to two passes - on the first pass, build the AST and whenever you find a variable name, add it to a list that contains that blocks' symbols (it would probably be useful to add that list to the corresponding scope in the tree). Step two is to linearly traverse the tree and make sure that each symbol used references a symbol in that scope or a scope above it.
My description is oversimplified but the basic answer is -- lookahead requires at least two passes.
The usual approach is to save B as "unknown". It's probably some kind of type (because of the place where you encountered it). So you can just reserve the memory (a pointer) for it even though you have no idea what it really is.
For the method call, you can't do much. In a dynamic language, you'd just save the name of the method somewhere and check whether it exists at runtime. In a static language, you can save it in under "unknown methods" somewhere in your compiler along with the unknown type B. Since method calls eventually translate to a memory address, you can again reserve the memory.
Then, when you encounter B and the method, you can clear up your unknowns. Since you know a bit about them, you can say whether they behave like they should or if the first usage is now a syntax error.
So you don't have to read all files twice but it surely makes things more simple.
Alternatively, you can generate these header files as you encounter the sources and save them somewhere where you can find them again. This way, you can speed up the compilation (since you won't have to consider unchanged files in the next compilation run).
Lastly, if you write a new language, you shouldn't use bison and flex anymore. There are much better tools by now. ANTLR, for example, can produce a parser that can recover after an error, so you can still parse the whole file. Or check this Wikipedia article for more options.