A small change (two bytes longer) to your solution makes it perfect, I think, for all cases
ClassMethod findShort(s) As %Integer
{
f i=1:1 ret:$locate(" "_s_" "," [^ ]{"_i_"} ") i
}BUT, and that's, what I want to say: this function is an awesome demonstration of economic nature of ObjectScript in comparison to Java. Your one-liner vs. a whole page of code... I love ObjectScript!
Sorry, that had to be said...
Take a look on the documentation of an (old) Cache instance (download the latest Cache 2018.x from WRC, if neccessary). There is a ZEN tutorial. You can follow the samples on IRIS, the ZEN classes are part of IRIS installation. Do not ask me for details, I have never used ZEN.
I'm sure, someone has a more elegant solution, anyway, I do it the quick-and-dirty way:
ClassMethod Lines(nsp = {$namespace})
{
s (cls,sum)=""
s glo=$na(^|"^"_##class(%SYS.Namespace).GetGlobalDest(nsp,"oddDEF")|oddDEF)
f {s cls=$o(@glo@(cls)),mth="" q:cls=""
f s mth=$o(@glo@(cls,"m",mth)) q:mth="" s sum=sum+$g(^(mth,30))
}
q sum
}
The only tricky thing is the (web)management portal. Put the following few lines into a "test.html" file and the open it with your favorite browser.
<html>
<head></head>
<body>
A simple text with some spaces<br>
<pre>A simple text with some spaces</pre>
</body>
</html>
You see the difference?
Did you check this or are you just saying that? What does this query show?
select MyColumn, length(MyColumn) from TableA
You can take the line from your own code, but with a suitable parameter
Set BASE64=BASE64_file.Read(someCount) // someCount = aNumber * 3For example 30000 instead of 32000. By the way, you read (8 bit) bytes, so there is no need to do the output-UTF8 conversion.
First of all, it's meaningless to post several KB of raw data. Either provide it somewhere for download or make an attachment (if possible).
Second, Base64 encodings converts 3 (incoming) bytes into 4 (outgoing) bytes, this means you always (except the last one) have to read multiple of 3 bytes at once, convert it, and put into the output stream. Your file.Read() reads 32000 bytes, which is NOT a multiple of 3!
After spending about 30 seconds on Google, I found following links
https://www.astm.org/e1394-97.html // ??
https://toolkits.horiba-abx.com/documentation/download.php?id=71068 // downloads a pdf
https://meganorms.com/st-astm-e1394-97.html
https://www.iso.org/obp/ui/#iso:std:iso:18812:ed-1:v1:en
... and many other links
Don't ask me,how accurate they are...
I have an (some ten years old) one which I use in the %ZSTART routine. Sometimes (for maintenance or whatever other reasons) you have to (re)start Cache and nowdays IRIS, but you want to start just some of the automatic processes listed in %ZSTART. If you forgot to disable those other before shutdown a init-file comes handy to disable things before start. A sample section looks like this:
[Start]
# 0 = do not start
# 1 = start
LoginServer = 1
UserLogin = 0
SystemTasks = 1
UserTasks = 0
I added some more comments to the class, you can download the InitFile.xml (class export) from my FTP server (which will be open for the next few days).
Addr: ftp.kavay.at
User: dcmember
Pass: member-of-DCsorry, in front of me is a linux... but what about
iris terminal <instanceName>
Does this work for you?
iris session <instanceName>should do the trick
The general syntax for calling routines from another namespace is:
do label^|namesapce|routine
where
- you can omit the label and
- namespace is either the name of the namespace (like set namesapce="USER") or the path to the database (preceded by two carets), where the routine resides.
I see right now, Config.MapGlobals accesses the ^SYS global via the path to the database (take a look at the Storage section) - so in theory, you can call all classmethods from the above class as:
do zClassmethodname^|"%SYS"|Config.MapGlobals.1(args...)
merely, I do NOT recommend to do this (the cass is in deployed mode, so we do not know, what the code really does and (instance)methods are private, so you can't call them from outside).
First, the correct (or better) way for the above code snipet were:
new $NAMESPACE
zn "%SYS"
do ##class(Config.MapGlobals).Delete(...)
quitsecond, one can call routines (and (class)methodes are compiled to rotines) from another namespace by using extended syntax, but in that case such a routine uses the globals (if the routine does a global access) from the CALLING namespace. In Your case this won't work because the Config.MapGlobals uses globals which resides in %SYS namespace and not in the namesspace you are in.
Sure, you can check some key points:
- the size of your PDF-file (in bytes) must be the same as the size of the context.strDocument
- the size of the encoded stream must be 1.33 times of the unencoded stream (see below)
- the second parameter of the Base64Encode() method must be set to 1, else you get a stream with line breaks!
set docSize = context.strDocument.Size
set encSize = context.strDocumentEncoded.Size
if -docSize#3+docSize*4/3-encSize { write "Base64 stream has wrong size" }
Your "old" version sent a string, the new version should send a stream - is there everything OK? Just double check all the recent changes.
If you have a (whatever) class with an property like:
Property propName As %Stream.GlobalCharacter;
and you have an instance of that object in a variable obj then a command like the below
write obj.propName --> nn@%Stream.GlobalCharacter
shows you the object reference, which is (formal) an integer number followed by an '@' symbol followed by the name of the class. With other words, what you see is correct.
you miss the object reference!
set context.strDocumentEncoded = B64EncodeStream(request.streamPDF)
// ---------------------------^^^^^^^ this should be something
set context.strDocumentEncoded = ##(your.class).B64EncodeStream(request.streamPDF)
but you have another problems too: your context.strDocument and context.strDocumentEncoded are currently STRING properties (according to the operation you try to do), which are limitet to a maxlength of 3.47MB!
You have to change both to a STREAM, so you can handle PDFs larger then ca. 2.6MB (because 2.6 * 4 / 3 ==> 3.46MB, the limit for a string variable).
After you change context.strDocument and context.strDocumentEncoded to a stream properties, you could use this code:
Class DC.Someclass Extends %RegisteredObject
{
Parameter CHUNKSIZE = 2097144;
ClassMethod ToBase64(src As %Stream.Object, dst As %Stream.Object) As %Status
{
i ..#CHUNKSIZE#3=0, src.Rewind(), dst.Rewind() {
set sts=$$$OK
while 'src.AtEnd,sts {
do dst.Write($system.Encryption.Base64Encode(src.Read(..#CHUNKSIZE,.sts),1))
}
} else { set sts=$$Error^%apiOBJ(5001,"Chunksize or src/dst-problem") }
quit sts
}
}if ##class(your.class).ToBase64(context.strDocument,context.strDocumentEncoded) write "OK"
It seems, this task will take some time... you have to check, how context.strDocument is populated and how context.strDocumentEncoded is later in code used. Good luck.
it looks like an OREF but it is just a string, try
set obj = [1,2]
write obj --> NN@%Library.DynamicArray
write $isobject(obj) --> 1
set ^myGlobal = obj
set obj=^myGlobal
write obj --> NN@%Library.DynamicArray
write $isobject(obj) --> 0
see also my answer in https://community.intersystems.com/post/handling-globalcharacterstream-production-service?page=1#comment-189746
It seems, you read the whole PDF into one string thenconverting this to Base64... So there are two "chances to get an error":
- the PDF is longer then the MAXSTRING value (which is 3641144 chars) and
- converting a string to Base64 increases the length of the string by a factor of 1.333 (you get your maxstr here).
The solution is: you read your PDF in chunks, convert this chunks into Base64 and output the converted data into a stream. Due to the nature of Base64, the length of the chunks you read in MUST BE a multiple of 3 (3 input bytes will be converted into 4 output bytes).
As an ObjectScript routine, remove the "ClassMethod" keyword (which, as the name indicates, belongs to classes. Then either add a "Public" keyword or you remove the brackets ("{", "}") too, but then all variables will have the same scope:
ProcData(file = "c:\temp\zipcitystate.csv") Public
{
set str=##class(%Stream.FileCharacter).%New()
do str.LinkToFile(file)
while 'str.AtEnd {
set $listbuild(ZIP,CITY,STATE)=$listfromstring(str.ReadLine())
// now you have the individual columns
// in ZIP, CITY and STATE variables for further processing
write "Zip=",ZIP,?12,"City=",CITY,?40,"State=",STATE,!
}
// depending on the way of your implementation, a "kill str"
// would be needed to free up the file
kill str
}Oh, and to invoke the above procedure just do a:
do ProcData^YourRoutineName()
// or
do ProcData^YourRoutineName("path-to-file")A simple method like
ClassMethod ProcData(file = "c:\temp\zipcitystate.csv")
{
set str=##class(%Stream.FileCharacter).%New()
do str.LinkToFile(file)
while 'str.AtEnd {
set $listbuild(ZIP,CITY,STATE)=$listfromstring(str.ReadLine())
// now you have the individual columns
// in ZIP, CITY and STATE variables for further processing
write "Zip=",ZIP,?12,"City=",CITY,?40,"State=",STATE,!
}
// depending on the way of your implementation, a "kill str"
// would be needed to free up the file
kill str
}to do the job. Then call the method as
do ##class(your.class).ProcData()
// or
do ##class(your.class).ProcData("path-to-the-file")
your exit statement
If (AxVisM1.P0.ToString = "") Then
Exit While
End Ifis to late, this must come after the $ORDER() statement
AxVisM1.Execute("set P0=$o(^ztonMS(""REF"",P0))")
If (AxVisM1.P0.ToString = "") Then
Exit While
End If
AxVisM1.Execute("s P1=$g(^ztonMS(""REF"",P0))")
The same goes for the next while-loop a few lines below
The standard ANSI escape sequenc should be:
write $c(27)_"[42m"_"Your green backround"_$c(27)_"[m"_" and a normal dot."
write $c(27)_"[32m"_"Your green text"_$c(27)_"[m"_" and a normal dot."
Bye the way, non of Cache/IRIS has an $ZU command but all versions have a bunch of $ZU() functions. So what do you want to do with them?
...
.SET SC=STREAM.LinkToFile(FILE) // A
...
...
.do ##class(%File).Delete(FILE, .RETURN) // BAs long you hold your hand on a file (line A), you can't delete the file (line B). You have to do something like
set SC = "" // or
kill SCThanks for the info about the evolution of the LIST functions.
I'm just a developer without any insight information into the internals of LIST functions and, as you wrote, "The changes were carefully done so that working programs that use functions of the form $LISTxxx, $Lx, and $LxS to manipulate $LIST strings will not notice the changes.", hence I do not saw any changes.
OK, there were some enhancements like adding $LV() and $LU() or a third argument to $LTS(), but those changes are not relevant for existing applications.
Regarding the speed gain by using (JSON)array instead of (JSON)object, yes you have right, the array variant is about 5% faster. I just didn't made a speed test for the new solution, the goal was to have a "legal solution" and not an all-time record.
Finally, I'll ask you, why are things like the internal format of $BIT() or $LB() unpublished?
For example, $LB() can't be such a big mystery because a simple ZZDUMP reveals the structure?
There are cases where this information would be (very) helpful. Just to name one, I have a particular case.
I wrote a simple class, which uses $ZF()-callouts, so the customer can create (i.e. export) data into an excel file (including formatting and colors) as well as read (i.e. import) data from an excel file (again, from *.xls and *.xlsx). The class has methods to read/write individual cells or whole rows or whole columns.
To pass row- and column-data between the application and the callout module, I use $LB().
set exl=##class(%Zu.Library.Excel).%New()
...
// writing data
do exl.WriteNum(row,col,value,format)
do exl.WriteRow(row,data) // data is $lb(col1, col2, ...colN)
// reading
set value=exl.ReadNum(row,col)
set data=exl.ReadRow(row) // data is $lb(col1, col2, ...colN)
...
To be able to write the corresponding callout module (Windows-DLL as well as Linux-SO), the information about the $LB() structure were esential.
This is just one example. Similar solutions were used for the PDF- and ZIP-callout modules too.
At least for the $LB() it shouldn't be such a big secret, and an official documentation would certainly make more happy customers. But it is not my decision, it must be decided by ISC.
To get all the jobGUIDs you need two loops:
f i=1:1:list1.Size f j=1:1:list1.GetAt(i).sensors.Size w list1.GetAt(i).sensors.GetAt(j).jobGUID,!
0b955ee7-9a54-4b13-9af1-7019721faeab
8f9e85ab-31e7-4835-8969-6d72d142a2f1
68cea9d3-54cd-43f2-ae37-aaf47ed43e6b
7602764e-8951-451f-9653-ceb84834a1a6
88d2e472-a1e4-40b3-a108-f2d32a2023e5
116f2ac6-da5f-46da-a7c7-92d9eaf98c89
a878e527-f519-4aaa-bf5d-0d65f72de119
be570b14-0555-4b86-ab9f-e37c40c79216
3a13e243-d6ed-4788-98b2-52e9213bee00
54969869-c4f6-43f6-a74a-2a67f9a73fc5
700af7d3-77b3-4a84-ba11-ea49602d6558
18dc3370-c291-468b-af1f-0361d95bb02c
35d0d2e7-1199-4c18-8941-4fff6dbdba1f
8044560c-94d2-4da7-87f5-07328d9e62c1
b636a2f5-d35f-4c82-9646-e09572336e23
9c9a4bf4-e8af-4b8d-9de2-a99cdff150ed
a576d235-6eb6-4312-a1ff-7b1f767b88ce
654cf21e-daad-4a11-b676-86a7bc8a3360
2be4efc8-6616-4bff-87ba-30fe388a1b34
a5374d6c-311c-44d0-8d06-3a31f33dd3a8
955529c5-36be-4f3e-b768-0e3b377804a7
60a7cdb0-499e-4d02-b4d3-06ee58e40481
e84eda78-1491-49af-9e34-d647e817a251
9bcd5fe6-6f05-4482-ad78-612f35c60b41
read json <now, Cntrl-V here the above string, press enter>, then
w ##class(%ZEN.Auxiliary.jsonProvider).%ConvertJSONToObject(json,,.list1) --> 1
w list1 --> 42@%Library.ListOfObjects
w list1.GetAt(1).sensors.GetAt(1).jobGUID --> 0b955ee7-9a54-4b13-9af1-7019721faeab
where is the problem?
From your JSON-String, someone stripped off two chars at the end: "}]"
So if you add those chars, everything will be OK
d ##class(%ZEN.Auxiliary.jsonProvider).%ConvertJSONToObject(JSONString3_"}]",,.list)
w list.GetAt(1).sensors.GetAt(1).jobGUID --> 0b955ee7-9a54-4b13-9af1-7019721faeab
I was told, it's illegal to use data structure information, which doesn't were changed in the last 25 years (and after this many years, one could think to have the right given by "customary law" to use it), hence I decided for a more "legal" solution for the above problem - although this solution will work for IRIS (and recent Cache systems) only:
Class DC.Test Extends %RegisteredObject
{
/// Return TRUE if val contains a string
ClassMethod IsString2(val) As %Boolean
{
quit {"a":(val)}.%GetTypeOf("a")="string"
}
/// Return TRUE if val contains a number (int, real or double)
ClassMethod IsNumber2(val) As %Boolean
{
quit {"a":(val)}.%GetTypeOf("a")="number"
}
}Oh, thanks for the hint, I'm aware of that. Actually one should remove the same characters as used in $locate():
if $locate($zstrip(data,"<w",",."), ...)but the point is, to circumvent such problems, the rule number one in the electronic data processing is: you have to apply for check each and every input (at least) a formal check or you end up with problems like this. So the desired process should be:
read_data --> check_it --> proceed_if_OK_else_back_to_input
The same goes for data during an import process.