Does DART support predefined macros such as:
__LINE__
or
__FUNCTION__
The reason for asking is that the transformer DART2JS makes the console log not useful as all the logs shows: js_primitives.dart:30
[update BasE]
When using the transformer dart2js, print("hello world"); will result in:
JS('void', r'console.log(#)', "hello world);
to be invoked from function: printString(String string)
residing in the library dart2js._js_primitives
This results that the console.log message always contains the same line number over and over again wherever in the DART code a print(); is used. (As console.log will add automatically the filename and line-number to the console display of the wrapper function residing in dart2js._js_primitives)
As the current implementation of adding file-name and line-number to the console.log message is useless, it would have been nice if there would be another method that allows to display additional information.
As example, print("hello world" __FUNCTION__ __LINE__); would result in additional debug information that can be more useful.
You could use
void main() {
print(StackTrace.current);
}
to get better information about the source of the error
DartPad example
You can also run your code in a custom zone and define a custom print method for that zone. See also https://api.dartlang.org/stable/1.24.3/dart-async/Zone/print.html
Seems what you are looking for is source maps that dart2js creates, that contain the information needed to recreate line numbers in original dart files, from the javascript locations.
Related
I am trying to create a util for logging.
I need to know the actual differences between print() vs debugPrint() and log().
Many answers I have seen are outdated or confusing. Also, some upvoted answers are contradict.
I am trying to print error messages in red color. I am using ANSI code to achieve it.
debugPrint("\x1B[31m HelloDebug \x1B[0m");
The above one print in red color.
But when i do the same using log(), its not printing in red color. Its escaping the ANSI code.
One thing I found out was log() has error parameter.
If i pass something as error , it handles red color by default.
Here in the first one using log, red is not coming because ANSI code is ignored. But in debugPrint using it's working fine. In third one it takes error red by default. But extra line is added even for empty string message.
Code:
Output:
Is it possible use ANSI code for making color text using log?
Because I have other ANSI code to make different color text.
I dont want use debugPrint because if I print some thing too frequently , the system ignore the logs.
After digging some time I found out that log function is implemented in c++ in the dart runtime.As the log function is external function in dart sdk.
external void log(
String message, {
DateTime? time,
int? sequenceNumber,
int level = 0,
String name = '',
Zone? zone,
Object? error,
StackTrace? stackTrace,
});
https://github.com/dart-lang/sdk/blob/main/runtime/lib/developer.cc
Also I see some different answers while digging.
The below answer says debugPrint only available inside widget class. Is it still true?
https://stackoverflow.com/a/52241553/9248098
EDIT:
While using debugPrint and when I launch app from Android studio terminal, the ANSI color is working in android but when I run it same in iOS its escaping the characters in same Android Studio terminal.
If ANSI code support is based on terminal support, I couldn't figure out why its having issue in same terminal in iOS.
It is well explained in this page Debugging Flutter apps programmatically
debugPrint() is similar to print() but with a throttles applied to prevents being dropped by Android’s kernel.
If you have linter setup on VSCode or other IDE, you will see this warning whenever you use print in your code. For more information, you can refer to Avoid print calls in production code.
To avoid the lint error, you can use kDebugMode with print or debugPrint instead.
if (kDebugMode) {
print('test print');
}
// OR
debugPrint('test debugPrint');
As for log(), it actually allows you to include more information on the logging output. For example, you can add the runtimeType and the relevant object in the log that can help you in debugging the code.
log(
'test log',
name: runtimeType.toString(),
error: myObj,
);
** btw I tried log with ANSI code log("\x1B[31m HelloDebug \x1B[0m");, it is working as expected.
I'm working on a personal project and I'm trying to get Lua to work on my embedded device.
I have my own simple file system that works with the the flash drive, and now I'm trying to use modules for the lua scripts that I run on the device.
I have edited linit.c, to make it also load the modules that are existing in the flash drive, and it works for a few modules, but for most of them it just gives me a syntax error when it parses the contents of the module. I have a lua interpreter running on my Windows machine and the code I'm writing is syntactically correct and works, and the Lua API that I use is of the same version 5.4 on the device.
These are the arguments I pass to
luaL_loadbufferx(L, luaCFunction, sizeOfModule, moduleName, "t")
where, L is the lua state, luaCFunction is the lua module wrapped in a C-style return statement, sizeOfModule, moduleName and t is selfexplanatory.
Right now luaL_loadbufferx is called in a loop for every module in my flash-drive, I have overwritten the openf function from the Lua API for these external modules.
This below is one of the examples of a module that gives me
"Syntax Error: PANIC, unprotected error in call to Lua API
[string "module"]:3: '(' expected near 'writeobj'"
File: module.lua
Contents:
function writeobj()
print('Hello World')
end
File: run.lua
Contents:
require ('module')
writeobj()
Does anyone know why this happens or did I not provide sufficient information? Please let me know.
The problem was that I thought the modules passed to the buffer had to be of the LuaToC form, i.e. "return { ...luamodule...}", but changing it to pass the module only to loadbuffer was sufficient enough because it covers the case of it not being in a C style return format.
I use VLC media player 1.1.9 on Ubuntu 11.04. I'm trying to experiment with lua extensions for VLC; so I've added the file test.lua in ~/.local/share/vlc/lua/extensions/, which has only these two lines:
fps="25.000"
frame_duration=1/tonumber(fps)
When I run vlc with verbose output for debugging, I get (edited to split on multiple lines:):
$ vlc --verbose 2
...
[0xa213874] lua generic warning: Error loading script
~/.local/share/vlc/lua/extensions/test.lua:
.../.local/share/vlc/lua/extensions/test.lua:2:
attempt to call global 'tonumber' (a nil value)
...
Now, as far as I know, tonumber as function is part of Lua5.1 proper (Lua 5.1 Reference Manual: tonumber) - and on my system:
$ locate --regex 'lua.*so.*' | head -4
/usr/lib/libipelua.so.7.0.10
/usr/lib/liblua5.1.so
/usr/lib/liblua5.1.so.0
/usr/lib/liblua5.1.so.0.0.0
... apparently I do have Lua 5.1 installed.
So, why do I get an error on using tonumber here - and how can I use this (and other) standard functions in a VLC lua extension properly?
Documentation is sparse for VLC Lua extensions to say the least but I did find an example in the github vlc repository here: https://github.com/videolan/vlc/blob/master/share/lua/extensions/VLSub.lua
Judging from that example it appears you need to supply some basic event functions for your addon for VLC to call into when certain events happen. Some of the obvious callback handlers I've noticed:
descriptor, this should return a table that contains fields describing your addon.
activate, this seems to get called when you activate it from view menubar.
deactivate, called when you deactivate the addon from view menubar.
plus a couple of other functions like close and input_change which you can guess what they're for.
From my brief testing done on VLC 2.0.8 under Win7 it appears VLC loads the lua extension using an empty sandbox environment. This is likely the reason you're getting nil for tonumber and I'm betting none of the other standard lua functions are accessible either when you try to perform computation at this global scope.
However, if I move that code into one of the event handling functions then all those standard functions are accessible again. For example:
function descriptor()
return
{
title = "Test Ext";
version = "0.1";
author = "";
shortdesc = "Testing Lua Extension";
capabilities = {};
description = "VLC Hello Test Addon";
}
end
function activate()
print "test activating"
local fps = tonumber "25.000"
local frame_duration = 1 / fps
print(frame_duration)
return true
end
-- ...
That prints out what you would expect in the console debug log. Now the documentation (what little there is) doesn't mention any of this but what's probably happening here is VLC is injecting the standard lua functions and vlc api table into the sandboxed environment when any of these event handlers get called. But during the extension loading phase, it is done in an empty sandbox environment which explains why all those lua function calls end up being nil when you try to use it at the outter most scope.
I recommend cloning the VLC source tree from github and then performing a grep on the C source that's embedding lua to see what VLC is really doing behind the scenes. Most of the relevant code will likely be here: https://github.com/videolan/vlc/tree/master/modules/lua
Probably some extension script installed in your system overwrites the function and the Lua interpreter instance is shared between all extension scripts, so you end up not being able to call the function if that script is called before yours.
As a quick workaround, Lua being dynamically typed, you can still do things like:
1 / "25.000"
and the string will be coerced to a number.
Alternatively, you can define a tonumber equivalent like:
string_to_num = function(s) return s + 0 end
This again relies on dynamic typing.
For debugging purposes it would be great to be able to see just what you are getting back from the map method. Is this possible in ruby?
To do this in the Mongo shell, you can define you own debug version of the emit() function to print trace information.
function emit(k, v) {
print("emit");
print(" k:" + k + " v:" + tojson(v));
}
Check out Troubleshooting MapReduce in the MongoDB docs for more info.
I know the Mongo documentation recommends defining your own emit function, but I find it easier to instead use print() directly in my map- and reduce-functions while I watch Mongo's log.
Just put any print()'s in your code, run tail -f /var/log/mongodb/mongodb.log, then run your code. You should see the print()'s output to the console.
Here's a few of the benefits:
Ability to debug the reduce() function – defining your own emit() doesn't help here
No need to define the emit() function every time you fire up the mongo console
Write your code in your editor instead of going back and forth between console and IDE
Ability to do code generation and variable interpolation in your native language
Do any editors honer C #line directives with regards to goto line features?
Context:
I'm working on a code generator and need to jump to a line of the output but the line is specified relative to the the #line directives I'm adding.
I can drop them but then finding the input line is even a worse pain
If the editor is scriptable it should be possible to write a script to do the navigation. There might even be a Vim or Emacs script that already does something similar.
FWIW when I writing a lot of Bison/Flexx I wrote a Zeus Lua macro script that attempted to do something similar (i.e. move from input file to the corresponding line of the output file by search for the #line marker).
For any one that might be interested here is that particular macro script.
#line directives are normally inserted by the precompiler, not into source code, so editors won't usually honor that if the file extension is .c.
However, the normal file extension for post-compiled files is .i or .gch, so you might try using that and see what happens.
I've used the following in a header file occasionally to produce clickable items in
the VC6 and recent VS(2003+) compiler ouptut window.
Basically, this exploits the fact that items output in the compiler output
are essentially being parsed for "PATH(LINENUM): message".
This presumes on the Microsoft compiler's treatment of "pragma remind".
This isn't quite exactly what you asked... but it might be generally helpful
in arriving at something you can get the compiler to emit that some editors might honor.
// The following definitions will allow you to insert
// clickable items in the output stream of the Microsoft compiler.
// The error and warning variants will be reported by the
// IDE as actual warnings and errors... which means you can make
// them occur in the task list.
// In theory, the coding standards could be checked to some extent
// in this way and reminders that show up as warnings or even
// errors inserted...
#define strify0(X) #X
#define strify(X) strify0(X)
#define remind(S) message(__FILE__ "(" strify( __LINE__ ) ") : " S)
// example usage
#pragma remind("warning: fake warning")
#pragma remind("error: fake error")
I haven't tried it in a while but it should still work.
Use sed or a similar tool to translate the #lines to something else not interpreted by the compiler, so you get C error messages on the real line, but have a reference to the original input file nearby.