I can read from system/ports/input (for example CGI data), but how do I write to this port so I can read it using read system/ports/input?
write system/ports/input some-data returns error cannot use write on port! value
The console scheme currently only supports a 'read actor.
See https://github.com/rebol/rebol/blob/master/src/core/p-console.c
I was going to say
system/ports/output
as well, but I noticed that it is 'none in my r3.
On the other hand, just using
print "something"
should automatically use standard output, which is used b cgi as well.
Related
I'm really lost with this, how can I read this response form an API HASH(0x1fcb970) using perl.
my #info= $connection->fetchrow();
When I try to print the data:
print #info
is when I get the HASH.
Something is a hash reference but is being treated as a string. When you stringify a reference, you get something like "HASH(0x1fcb970)" instead of what you intended or expected. You see numbers that look like they may be a memory address, but those aren't useful to you.
You might start by inspecting what you got:
use Data::Dumper;
print Dumper( \#info );
If you see what you expect there, then it's on your side to treat the reference properly.
If it's an error on the API side. Open a ticket with them and have them fix it.
There was a major newspaper that had this happen to them in 1990s, as I recalled. All of their headlines were "HASH(0x...)" for a couple of hours. :)
Hi I want to take input from user in my
DO BEGIN and END block...
I tried to use /prompt inside but it doesnt work.
Do we have any other way that we can use it inside function or block in postgres?
Important note: PLpgSQL is server side only language - there is not any possibility do any user interactivity operation. You have to collect input on client side before start of PLpgSQL code, and user input push there as parameters.
DO statement is server side statement, so you cannot do any interactive action there.
DO statement doesn't support parameters so it is not easy push any parameters inside DO statement, but is possible with custom configuration variables:
\prompt 'enter some text: ' psqlvar
\o /dev/null
select set_config('psql.psqlvar', :'psqlvar', false);
\o
do $$
DECLARE var text = current_setting('psql.psqlvar');
BEGIN
RAISE NOTICE 'entered text is: %', var;
END;
$$;
The function set_config is used to moving a content of client variable :psqlvar to server side - session variable psql.psqlvar. The content of this server side variable is taken by function current_setting.
You have to separate in your mind server side and client side content. The DO statement is evaluated on server side. The psql \prompt command is evaluated on client side.
As bad ideas go, asking for user input in a stored procedure is up there with using usernames as session identifiers. This is a really, really bad idea. Yes there are ways in some environmnets to do this. But just because you can does not mean you should. For example I have heard of people using pl/python to make a network connection back to the client computer and ask for more information. However, this is frankly DailyWTF territory. It also assumes a protocol and listener on the client to ask for this request and therefore doesn't work from pgadmin.
Now, DO creates an anonymous function without arguments and immediately executes it. This seems to be where your real problem is.
Your best solution is to just create an actual function with arguments and accept the input there. Then it can be used anywhere. And you can re-use, modify security, etc. This sounds like it is exactly what you need.
Failing that you could preprocess your do block before you send it.
Your best design where you want to reuse PL/PGSQL code with inputs is to use a function (see CREATE FUNCTION) instead of DO (note you can put these in another schema if that is a concern).
According to MSDN vb.net uses this extended character set. In my experience it actually uses this:
What am I missing? Why does it say it uses the one and uses the other?
Am I doing something wrong?
Is there some sort of conversion tool to the original character set?
This behaviour is defined in the documentation of the Chr command:
The returned value depends on the code page for the current thread, which is contained in the ANSICodePage property of the TextInfo class in the System.Globalization namespace. You can obtain ANSICodePage by specifying System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage.
So, the output of Chr for values greater than 127 is system-dependent. If you want reproducible results, create the desired instance of Encoding by calling Encoding.GetEncoding(String), then use Encoding.GetChars(Byte()) to convert your numeric values into characters.
If you go up one level in the chart linked in your question, you will see that they do not claim that this chart is always the output of the Chr command:
The characters that appear in Windows above 127 depend on the selected typeface.
The charts in this section show the default character set for a console application.
Your application is a WinForm application, not a console application. Even in the console, the character set used can be changed (for example, by using the chcp command), hence the word "default".
For detailed information about the encodings used in .net, I recommend the following MSDN article: Character Encoding in the .NET Framework.
The first character set is Code Page 437 (CP437), the second looks like Code Page 1252 (CP1252) also known as Windows Latin-1.
I'd guess VB.Net is simply picking up the default encoding for the PC.
How did you write all this? Because usually, when you use a output stream function, you can specify the encoding going with it.
Edit: I know this is not C#, but you can see the idea...
You'd have to set the encoding of your filestream, by doing something like this:
Setting the encoding when creating the filestream
I haven't used tcl before and just need to do one trick, I can do it trivially in something like bash but I need it to work cross-platform (e.g. tcl in cygwin on windows).
Can someone suggest a short (5-10) obfuscated function that just returns 0 after taking two string args? It just can't do something like run shell commands that won't work under Mac/Cygwin.
fwiw, why do this: buying some time in writing a test- the thing generating one of the files is broken but I can't change it, making a hack in the TCL test script until I make extensive changes to use a different 'test core' that isn't broken. For now just declare the first file as 'good' if it exists.
I don't understand the requirement for obfuscation, but the simplest way to create a command that takes two arguments and returns 0 is this:
proc theCommandName {firstArgument secondArgument} {
return 0
}
There are all sorts of ways of making things obscure (e.g., a regular expression that doesn't actually match anything, a complicated expression) but as I said before, I don't understand the requirement in that area; I always try to make my code be the simplest thing that could possibly work…
First, i admit all the things i will ask are about our homework but i assure you i am not asking without struggling at least two hours.
Description: We are supposed to add a field called max_cpu_percent to task_struct data type and manipulate process scheduling algorithm so that processes can not use an higher percentage of the cpu.
for example if i set max_cpu_percent field as 20 for the process firefox, firefox will not be able to use more than 20% of the cpu.
We wrote a system call to set max_cpu_percent field. Now we need to see if the system call works or not but we could not get the value of the max_cpu_percent field from a user-spaced program.
Can we do this? and how?
We tried proc/pid/ etc can we get the value using this util?
By the way, We may add additional questions here if we could not get rid of something else
Thanks All
Solution:
The reason was we did not modify the code block writing the output to the proc queries.
There are some methods in array.c file (fs/proc/array.c) we modified the function so that also print the newly added fields value. kernel is now compiling we'll see the result after about an hour =)
It Worked...
(If you simply extended getrlimit/setrlimit, then you'd be done by now…)
There's already a mechanism where similar parts of task_struct are exposed: /proc/$PID/stat (and /proc/$PID/$TID/stat). Look for functions proc_tgid_stat and proc_tid_stat. You can add new fields to the ends of these files.