CP1600-series processor support.

Documentation for the instruction set is at http://bitsavers.trailing-edge.com/components/gi/CP1600/CP-1600_Microprocessor_Users_Manual_May75.pdf (pages 53-58) - since instructions are all described inside tables condensed in just 5 pages I didn't add a manual index.  If that's required as a criterion for merging that can be easily added, though.

I'll try to rework this to use wordsize=2 in the ram space so things might be a bit cleaner - if history will get too messy I'll close this, squash and submit a new PR, I think.

Ok, here it is - I'd love for this to be squished to make history a lot cleaner than it would be otherwise, though.

I would leave this PR open.  You can squash your branch (leave the first line as pick and change the rest of the commits to squash, write that to file, and then it will give you a chance to cleanup the commit message) and force push
git rebase -i d594315ec7f33a87da3e8cde05ff0bdb8938bf38
git push --force

I'm not sure what is the repo policy for Ghidra about force pushes actually, as I also try to avoid them myself if I can.  If this doesn't bother anyone I'll just squash this up, then.

Ok, Eclipse's git thingie got confused when squashing and pulled in two extra commits.  I'm not much of a git wizard to unravel this myself, so I think I can just close this and reopen it with a new branch in my fork :|

Ok, it took a few hours but I managed to restore the git repo as it was supposed to be.

The readDoubleWord and readHalfDoubleWord look like they could use improvement.
A possible approach would be add another token field that mirrors the register value, but not attached (op3_5=(3,5) ) and build constructors for the implied addressing and handle the pre/post increment:
impl_addr:  reg3_5 is reg3_5 & doublebyte=0 & op3_5=1 or op3_5=2 or op3_5=3
{
    local tmp:2 = zext(*:1 reg3_5);
    tmp = tmp | (zext(*:1 reg3_5) << 8);
    export tmp;
}
impl_addr:  reg3_5 is reg3_5 &  doublebyte=0 & op3_5=4 or op3_5=5
{
    local tmp:2 = zext(*:1 reg3_5);
    reg3_5 = reg3_5 + 16;
    tmp = tmp | (zext(*:1 reg3_5) << 8);
    export tmp;
}
impl_addr:  reg3_5 is reg3_5 & doublebyte=1 & op3_5=1 or op3_5=2 or op3_5=3
{
    local tmp:2 = *:2 reg3_5;
    export tmp;
}
impl_addr:  reg3_5 is reg3_5 &  doublebyte=1 & op3_5=4 or op3_5=5
{
    local tmp:2 = *:2 reg3_5;
    reg3_5 = reg3_5 + 16;
    export tmp;
}
impl_addr:  reg3_5 is reg3_5 &  doublebyte=1 & op3_5=6
{
    reg3_5 = reg3_5 - 16;
    local tmp:2 = *:2 reg3_5;
    export tmp;
}

would give:
:ADD@ impl_addr, reg0_2 is opcode6_9=0x000B & reg0_2 & impl_addr [ doublebyte=0; globalset(inst_next, doublebyte); ] {
	addition(reg0_2, impl_addr);
}

i don't 100% understand the implied addressing setup, so this may not be correct as is, but along these lines

First off, thank you for submitting the processor.  Been a bit since the internal review was started on this.  Someone started the review and it got into a covid backlog.  I'm looking to merge this in to our processor set.  However I'm seeing some issues with some of the instructions.  Lacking any examples, I poked in a few from the manual, and found some problems.  The biggest issues are with the flow instructions.  I can accept the pull request and fix them, or I can try and describe them for you with the fixes I did locally to try and understand what was going on with the processor.
There are some issues with the setting of the R7 pc for goto/return.
Some synthetic instructions like PSHR/PULR, CLRR that are not implemented.
The decompiler doesn't work on it.  Need to check why.
The register calling convention should probably include R0, R1, R2, R3 just for start, and maybe R0 as the return.
Some branch targets appear off by 1, by doing a one's complement and adding for negative offsets, it appears to get to the correct address.
Anytime the R7 register is the destination, there must be a branch to the value.  Most of the time this could be a GOTO [R7], however the JSR  is generaly a RETURN [R7].
Anytime the R7 register is accessed, the value of the current instruction should be used.  I see an INCR R7, used to skip the next instruction, so I believe the value should be inst_next when using the value in R7.
There might be a few more, but that is most of what I spotted.
If you'd like to fix the issues and then repush, I can comment directly in a review.  If you rather me do them at this point because you've moved on, I can do that too.

slightly off-topic, but @emteere  really good to see you here (specially posting in this manner), hopefully all is going well with the you and the Ghidra team, and that your transition back to the workplace is going well.

@mumbel thanks for the good words.  Everyone on the team is good, but a little constrained along with the rest of the world.

@emteere thank you for taking a look at this - no worries for the delay in taking on this.
That said, the issues you raise are indeed valid and I'll have a go at finishing to sort them all out soon.  Regarding the calling convention, all the available documentation I found had no clear definition and there wasn't any C compiler ever written for this microcontroller either.  As far as I've seen, the calling convention in use is to stuff parameters right after the JSR opcode and then adjust the value of R7 upon exit to point at the end of the parameters block.  I've left the default calling convention empty for that reason, as I think it should be handled by either a GhidraScript file or by Java code in the plugin.
Also, I've rebased my internal tree to the latest HEAD, and I noticed that the mapped program counter isn't taken into account when calculating offsets.  So, for these two Sleigh opcodes based on the current version of the .slaspec file:
define token opcode_word (16)
	# ...
	target0_2          = (0, 2)
	# ...

:INCR reg0_2 is opcode3_9=0x0001 & reg0_2 & target0_2 {
	reg0_2 = reg0_2 + 1;
	resultFlags(reg0_2);
	local target:2 = target0_2;
	if (target != 7) goto inst_next;
	goto [R7];
}

#...

:MVII "#"imm16, reg0_2 is opcode3_9=0x0057 & reg0_2 & target0_2 ; imm16 {
	reg0_2 = imm16;
	local target:2 = target0_2;
	if (target != 7) goto inst_next;
	goto [R7];
}

#...

and I have this bit of code:
	MVII #label, R7
	NOP
label:
	NOP
	NOP
	NOP
	NOP
	INCR R7
label2:
	NOP

the INCR R7 opcode target instead of pointing to label2 ends up pointing to one opcode past label, which isn't really correct (even though R7 is set as the program counter register in the .pspec file).  Am I doing things wrong or is it a bug in Ghidra?

uh oh, you went to 558 commits, I would see if you could undo that merge (there's no real need to merge into this branch).

For the branching case, I wouldn't implement it this way.  Normally goto's should be avoided in pcode.  Special cases should either be a separate constructor, or handled in a sub-constructor.
The second case is actually the JR:
:JR reg3_5 is opcode6_9=0x0002 & reg0_2 & reg3_5 & reg0_2=7 {
	reg0_2 = reg3_5;
	resultFlags(reg0_2);
	return [reg0_2];
}

The first can be handle like something like this when there is the possibility that there could be a branch (there are other ways, like splitting the sub-constructor:
checkBranch: is reg0_2=7 {
	goto [R7];
}
checkBranch: is reg0_2 {
}
.
.
.
:INCR reg0_2 is opcode3_9=0x0001 & reg0_2 & checkBranch {
	reg0_2 = reg0_2 + 1;
	resultFlags(reg0_2);
	build checkBranch;
}

I believe the issue with the bad branch target is because the value needs to be a 1's complement subtraction.  I redid it as below and it worked better.
branchdest16:  reloc is branch_sign=0 ; imm16   [ reloc = inst_start + 2 + imm16;          ]   { export *:2 reloc;                         }
branchdest16:  reloc is branch_sign=1 ; imm16   [ reloc = inst_start + 2 + (imm16 ^ 0xffff); ] { export *:2 reloc;                         }

I added the CLRR, PULR, PSHR instructions.  Note, I normally don't like (b0305 = b0002) match comparisons, but the field is only 3-bits, and it is a very small processor.
:CLRR reg3_5 is opcode6_9=0x0007 & (b0305 = b0002) & reg0_2 & reg3_5 {
	reg0_2 = 0;
	resultFlags(reg0_2);
}

:PULR reg0_2 is opcode6_9=0x000A & reg0_2 & impliedval16 & target3_5=6 {
	reg0_2 = impliedval16;
}

:PSHR reg0_2 is opcode6_9=0x0009 & reg0_2 & reg3_5 & target3_5=6 {
	local ptr:2 = reg3_5;
	*ptr = reg0_2;
	reg3_5 = reg3_5 + 1;
}

Here's the bytes for the two sample programs I typed in from mangled octal text conversion.    The registry strategy for a calling convention is meant to be ad-hoc.  It allows the decompiler to detect the parameters for the define registers as it sees use of them.  So it isn't a normal C type calling convention.  Most small processors have this convention if they might have hand coded assembly.  It could also have the stack in there, but I didn't do that since that might complicate things.  Could be added later.
There is an interrupt calling convention that uses the stack, but it probably isn't worth adding.
Also note the stack is positive growing.
  <stackpointer register="R6" space="ram" growth="positive"/>
  <default_proto>
    <prototype name="asm" extrapop="0" stackshift="0" strategy="register">
      <input>
        <pentry minsize="1" maxsize="2">
          <register name="R0"/>
        </pentry>
        <pentry minsize="1" maxsize="2">
          <register name="R1"/>
        </pentry>
        <pentry minsize="1" maxsize="2">
          <register name="R2"/>
        </pentry>
        <pentry minsize="1" maxsize="2">
          <register name="R3"/>
        </pentry>
        <pentry minsize="1" maxsize="2">
          <register name="R4"/>
        </pentry>
        <pentry minsize="1" maxsize="2">
          <register name="R5"/>
        </pentry>
      </input>
      <output>
        <pentry minsize="1" maxsize="2">
          <register name="R0"/>
        </pentry>
      </output>
      <unaffected>
        <register name="R6" />
      </unaffected>
    </prototype>

Just setting the program counter register doesn't cause a computation.  There isn't an assumption of the R7 value, you would need to provide the value.  The reason behind this is that each processor handles the current value of the PC differently.  It could be inst_start, inst_next, inst_start+4, ...  depending on the situation.  You can't assume what it will be set to at any given time.
So in order to do this, you need to know what R7 would be if the value is accessed.  You could do it this way:
checkBranch: is reg0_2=7 {
	goto [R7];
}
checkBranch: is reg0_2 {
}

regVal: is reg0_2=7 { export inst_next; }
regVal: is reg0_2 { export reg0_2; }

:INCR reg0_2 is opcode3_9=0x0001 & reg0_2 & regVal & checkBranch {
	reg0_2 = regVal + 1;
	resultFlags(reg0_2);
	build checkBranch;
}

Or
:INCR reg0_2 is opcode3_9=0x0001 & reg0_2 & b0002=7  {
	reg0_2 = inst_next + 1;
	resultFlags(reg0_2);
	goto [reg0_2];
}

:INCR reg0_2 is opcode3_9=0x0001 & reg0_2 & b0002 {
	reg0_2 = reg0_2 + 1;
	resultFlags(reg0_2);
}

Not sure which is more work.  Probably the first might be easier to do and creates less new constructors and should work with all instructions.  R7 might have some undefined behavior in certain cases when accessing the value or assigning to it.

Should try my suggestions first...
checkBranch: is reg0_2=7 {
	goto [R7];
}
checkBranch: is reg0_2 {
}

regVal: is reg0_2=7 { local tmp:2 = inst_next / 2; export tmp; }
regVal: is reg0_2   { export reg0_2; }

:INCR reg0_2 is opcode3_9=0x0001 & reg0_2 & regVal & checkBranch {
	reg0_2 = regVal + 1;
	resultFlags(reg0_2);
	build checkBranch;
}

                    ram:001d 00 0f               -2           INCR            R7=>LAB_001f
                                                      $U6a0:2 = INT_DIV 60:2, 2:2
                                                      R7 = INT_ADD $U6a0, 1:2
                                                      Z = INT_EQUAL R7, 0:2
                                                      S = INT_SLESS R7, 0:2
                                                      BRANCHIND R7
                             LAB_001e                                        XREF[2]:     ram:0011(j), ram:0015(j)
                    ram:001e 00 14               -2           DECR            R4
                                                      R4 = INT_SUB R4, 1:2
                                                      Z = INT_EQUAL R4, 0:2
                                                      S = INT_SLESS R4, 0:2
                             LAB_001f                                        XREF[1]:     ram:001d(j)
                    ram:001f 02 b2               -2           PULR            R2
                                                      R6 = INT_SUB R6, 1:2
                                                      $Uc0:2 = LOAD ram(R6)
                                                      R2 = COPY $Uc0

@mumbel seems that rebasing confused things up a bit, it should be fixed now.

@emteere thanks for all the comments, I'll see what I can do with that - didn't know about the build keyword actually!
Anyway, I think I'll go with the checkBranch constructors as it looks simpler as you mention...  Is the other case (adding an extra constructor on each instruction that may write to R7) still affected by the same undefined behaviour as checkBranch?

By the way, is it possible to inhibit creation of single byte constants (or rather half-words) since such a thing does not exist for this microprocessor?
The slaspec file has define space ram type=ram_space wordsize=2 size=2 default; so it looks like the minimum entity size would be two bytes instead, yet half-word constants can be defined in the code.  (Yes, this space should be renamed from ram to CODE or something else...)

By inhibit creating single byte constants, do you mean defining data item of a byte vs word?
There might be times that you want to do that say where there really is two different data items in one two byte word.
You can provide values for the data organization (size of short, int, pointer, etc...) in the .pspec file, but I don't think that would inhibit creating a byte.

The build keyword is there so that you can force a sub-constructors p-code to get woven in at the correct location.  Most cases it isn't needed.  I like to use it to show when something should occur like the check for flow.
For the checkBranch, separating the constructors wouldn't have undefined behavior for setting the R7 branch, since it checks for it directly.  I think the checkBranch is probably better since you can use it in all the instructions as you mention.

By inhibit creating single byte constants, do you mean defining data item of a byte vs word?
There might be times that you want to do that say where there really is two different data items in one two byte word.
You can provide values for the data organization (size of short, int, pointer, etc...) in the .pspec file, but I don't think that would inhibit creating a byte.

Yep, basically disabling byte data items.  Considering that the smallest data item size is at the very least 10 bits, that makes things a bit awkward.  That'd also mean that automatic data labels should be word-sized and not byte-sized too - same for absolute offsets, that are effectively 32-bits wide and also word-swapped when defined.  Granted, manually adding references is an option here, but it's rather painful actually - for example, when examining a firmware image for this microcontroller I wasn't able to find a way to recycle reference editor panes when adding them to offset tables and the like, so after a couple of hours I ended up with a few hundred reference editor tabs in a docked pane...
I wonder if the address/constant fixup can be done automatically by overriding some Ghidra functions in a processor-specific plugin or if this calls for a GhidraScript file to be ran regularly to merge and re-cast already defined entries in the listing - maybe not at this stage, of course.
 :)

I also forgot one (minor) thing, the byte-word mismatch also makes strings impossible to have unless they're defined as unicode - which may or may not a problem depending on the situation if you have other things going on like scripts or plugins that look for ASCII strings in particular.

The auto-data labels and sizes are based on the loads that are made to the address, so that if it pulls 2 bytes, you'll get an undefined2 defined there.  It would also only create word offsets, not byte offsets.
I'd have to see an example to understand better.  Anything you can share, even a small example?
I see the strings issue, but they could also pack the strings in to each word and not one character per word.

The firmware I'm looking at is declaring jump tables with something like this (please ignore the fact that targets are all close together, the binary I'm working with has entries pointing in totally different areas of ROM space):

	ROMW	16
	ORG	$8000

	; R0 is the index in the jump table
	MVII	#table, R4
	SLL	R0, 1
	ADDR	R0, R4
	SDBD
	MVI@	R4, R5
	JR	R5

label1:
	HLT
label2:
	HLT
label3:
	HLT
label4:
	HLT

table:
	BIDECLE label1
	BIDECLE label2
	BIDECLE label3
	BIDECLE label4

which when opened in Ghidra and after starting to disassemble from the first instruction looks like this:

and with some more renaming and adding labels looks like this (EOL comments are mine):

Notice that the address have their words swapped.  Now, the words are encoded just like that in the binary file:
❯ xxd test.bin
00000000: 02bc 800b 0048 00c4 0001 02a5 00af 0000  .....H..........
00000010: 0000 0000 0000 0007 0080 0008 0080 0009  ................
00000020: 0080 000a 0080                           ......

but the only way those values can be consumed (as far as I know) are through SDBD-modified opcodes which - if they are supposed to read two separate, consecutive values - read the low 10 bits first and the high 10 bits first before combining them.
If overriding the data items creation behaviour via a plugin is possible and it is fine to bring it in, I'll look into that too.

Regarding the BIDECLE data types, I came up with https://gist.github.com/agatti/a1c9b57fa7b4d7129aa1b09f8c62f149 and https://gist.github.com/agatti/150f1db354c2503280ffe25462e5f6f7.  I'm not terribly proud of the implementation but it seems to work...  Unfortunately I wasn't able to easily see if I could restrict those data types to CP1600 files, even if said files are put in the processor plugin.
I'll also look into making memory-accessing opcodes use bidecles when necessary, but that may take a bit more time I guess.

Ah, now I understand.  It has split the address into two parts.
If you modify the flow of the JR to be a jump and not a call, the switch stmt may recover.  If there is a guard on the switch, the switch may recover automatically.  The decompiler is really finicky sometimes, especially with the way the jump targets are created for this switch with the MOVI.
I modified your example a bit to provide a guard, and I had to mess with the MVI@ indexing.  It should be equivalent, but it reads memory once.  Not sure it will improve other code, but it was necessary to get the switch to recover.
                             //
                             // switch
                             // ram: 8000-807f.1
                             //
                             **************************************************************
                             *                          FUNCTION                          *
                             **************************************************************
                             <DEFAULT>     undefined FUN_8000()
             undefined         R0:1             <RETURN>
                             FUN_8000
                 switch:8000 03 78 00 04          0           CMPI            0x4,R0
                 switch:8002 02 05 00 01          0           BLT             LAB_8005
                             LAB_8004                                        XREF[2]:     switch:8007(j), switch:800f(j)
                 switch:8004 00 af                0           JR              R5
                             LAB_8005                                        XREF[1]:     switch:8002(j)
                 switch:8005 03 78 00 00          0           CMPI            0x0,R0
                 switch:8007 02 05 ff fb          0           BLT             LAB_8004
                 switch:8009 02 bc 80 14          0           MVII            0x8014,R4
                 switch:800b 00 48                0           SLL             R0,1
                 switch:800c 00 c4                0           ADDR            R0,R4
             assume doublebyte = 0x1
                 switch:800d 00 01                0           SDBD
                 switch:800e 02 a5                0           MVI@            R4,R5=>DAT_8014
             assume doublebyte = <UNKNOWN>
                             switchD_800f::switchD
                 switch:800f 00 af                0           JR              R5
                             -- Flow Override: BRANCH (COMPUTED_JUMP)
                             LAB_8010                                        XREF[1]:     switch:800f(j)
                 switch:8010 00 00                0           HLT
                             LAB_8011                                        XREF[1]:     switch:800f(j)
                 switch:8011 00 00                0           HLT
                             LAB_8012                                        XREF[1]:     switch:800f(j)
                 switch:8012 00 00                0           HLT
                             switchD_800f::switchdataD_8013                  XREF[1]:     switch:800f(j)
                 switch:8013 00 00                0           HLT
                             DAT_8014                                        XREF[1]:     switch:FUN_8000:800e(R)
                 switch:8014 00                               ??              00h
               switch:8014.1 10                               ??              10h
                             DAT_8015                                        XREF[2]:     ram:0880(R), ram:0989(R)
                 switch:8015 00                               ??              00h
               switch:8015.1 80                               ??              80h
                             DAT_8016                                        XREF[3]:     ram:0880(R), ram:0885(R),
                                                                                ram:0989(R)
                 switch:8016 00                               ??              00h
               switch:8016.1 11                               ??              11h
                             DAT_8017                                        XREF[1]:     ram:0885(R)
                 switch:8017 00                               ??              00h
               switch:8017.1 80                               ??              80h
                 switch:8018 00                               ??              00h
               switch:8018.1 12                               ??              12h
                 switch:8019 00                               ??              00h
               switch:8019.1 80                               ??              80h
                 switch:801a 00                               ??              00h
               switch:801a.1 13                               ??              13h
                 switch:801b 00                               ??              00h
               switch:801b.1 80                               ??              80h
                 switch:801c 00                               ??              00h

03 78 00 04 02 05 00 01 00 af 03 78 00 00 02 05 ff fb 02 bc 80 14 00 48 00 c4 00 01 02 a5 00 af 00 00 00 00 00 00 00 00 00 10 00 80 00 11 00 80 00 12 00 80 00 13 00 80 00

I changed the impliedval16 to:
impliedval16: reg3_5 is reg3_5 & (target3_5=4 | target3_5=5) & doublebyte=1 {
#	local tmp:2 = zext(*:1 reg3_5);
#	reg3_5 = reg3_5 + 1;
#	tmp = tmp | (zext(*:1 reg3_5) << 8);
#	reg3_5 = reg3_5 + 1;
#	export tmp;
	local idx:2 = reg3_5;
	local val:4 = *:4 reg3_5;
	local low:1 = val(2);
	local high:1 = val(0);
	local tmp:2 = (zext(high) << 8) | zext(low);
	reg3_5 = reg3_5 + 2;
	export tmp;
}

void FUN_8000(undefined2 param_1)
{
  if (true) {
    switch(param_1) {
    case 0:
      do {
                    /* WARNING: Do nothing block with infinite loop */
      } while( true );
    case 1:
      do {
                    /* WARNING: Do nothing block with infinite loop */
      } while( true );
    case 2:
      do {
                    /* WARNING: Do nothing block with infinite loop */
      } while( true );
    case 3:
      do {
                    /* WARNING: Do nothing block with infinite loop */
      } while( true );
    }
  }
  return;
}

Also looks like there is something wrong with the switch table markup for word addressing.  Must be assuming byte offsets somehow.

Yep, much much better with those changes to impliedval16 indeed!
Regarding the switch table markup - that's "fixed" via the BIDECLE/SBIDECLE gists I posted earlier - it's all depending on the fact that even if the CPU is big-endian, SDBD-modified opcodes read multi-word data in a little-endian fashion.
If manually adding 'bidecle'/'sbidecle' types is too tiring maybe an extra instruction analyser should be added to codebase to automatically create such types, where those data types gists can be put to some use - which is sort of what I plan to be looking into - possibly as a separate PR, along with a first shot at a subroutine analyser (turns out that page 63 of https://archive.org/details/bitsavers_giCP1600CPsersManualMay75_9917417 actually does define an informal calling convention, after all).
I'll merge your slaspec changes right away then.


Problem with string sanitation of $\theta$

hv.HoloMap({i: hv.Path((range(3), np.random.rand(3))) for i in range(3)}, key_dimensions=['$\theta$'])

gives:

edit:
I just realised r'$\theta$' fixes the problem, but $\phi$ does work.

Odd... I assume this is because \t is the escape code for tabs in Python. I assume there is a similar problem with \n and the other escape codes.
I'm not sure what the best solution is but using the raw string is probably the easiest thing for now...

As Jean-Luc pointed out this is to do with the various escape codes. When using LaTeX you should either escape the escape codes explicitly or use a raw string as you have done. There's nothing we can really do about this so I'll close the issue.

When using LaTeX you should either escape the escape codes explicitly ...

I'm not sure this is the only solution. For instance, we could automatically replace \a with \\a because I doubt we want the system bell in our dimension strings. :-)
You can find the list of escape codes here and we would need to decide what should or shouldn't be allowed. For instance, should we really support tabs in dimension names? Maybe it would be better to automatically convert \t into \\t because \theta (and any other LaTeX code beginning with \t) might be the more common and useful case.

This might be worth considering but I do have one minor objection. Presumably we wouldn't want to escape the newline character \n , which means our handling would be inconsistent. You could do '\theta' but would need r'\nu. I don't have a strong opinion on this though.

Presumably we wouldn't want to escape the newline character \n

I'm not convinced that multi-line dimension labels really make sense anyway. Which means I would probably be in favor of escaping everything to be consistent.

What's wrong with requiring users to double-escape LaTeX code used here, i.e. ``$\theta""?

What's wrong with requiring users to double-escape LaTeX code used here, i.e. $\theta$?

That would work but the idea here is to make it as easy for the user as possible. Raw strings already get around this problem and the reason to avoid this escaping is so people can set labels without thinking too much about it.

Hmm.  I guess just saying that no control characters will be respected is fine.  We could always put in something to make \\n work as a newline, if having newlines were desirable.


Use ipmitool's -a option instead of passing the password on the command line.

If ipmitool is running on a system and a user does ps aux, it's possible to view the arguments it was called with. Right now we're passing the obm's password as a command line argument, which is a problem. Interestingly, the machine I spotted this on was smart enough to replace the actual password with XXXXXX, but we should probably just use -a, which prompts us for the password, and then feed it in on stdin instead.

the machine I spotted this on was smart enough to replace the actual password with XXXXXX

haha, I thought you did something in obmd to mask the password.
But it would be a good idea to use -a option.


MOLPay: Initial Commit

 Issue by saifiikmal
Friday Apr 25, 2014 at 03:05 GMT
Originally opened as https://github.com/Shopify/active_merchant/pull/1143

Please review as this is initial commit for MOLPay to Active Merchant. TQ

saifiikmal included the following code: https://github.com/Shopify/active_merchant/pull/1143/commits

MOLPay was merged; closing this.


Country typo

$faker->country provide me "Palestinian Territory", should be "Palestinian Territories"

Palestinian Territories aren't present in the fr_FR\Address, I think it's the same for some locales.

Fixed in #996


Feat: parsers in the demo

Would be cool if you could specify the parser in the demo - obviously the website needs to make the parsers available. This would be pretty cool to test stuff in typescript-eslint-parser, babel-eslint etc., especially to compare if a certain bug exists in vanilla eslint or in the parser

It could be a pain in the rear end to have to maintain extra parser dependencies, track versions, etc. Can this be done in a clever way that doesn't require a lot of maintenance on our end?

It would be cool, but I don't think anyone has the time or desire to build out the demo in such a way where this would be possible. Unless you want to submit a pull request, it's unlikely this will be addressed.

Closing this since there hasn't been any discussion in quite a while and progress on the issue has stalled. While we wish we could accommodate all requests, we have limited resources and do need to prioritize.
Feel free to open a new issue with a proposal to continue this discussion if this is something you would like to continue advocating for.


Fixed exception when generating actions with model binding.

Fixed bug where swagger generator would throw an exception if the parameters were bound on modelBinding, services or custom before allowing the operation filters to remove the parameters.  I moved the validation check to happen after the filters get applied.

@LammyL - thanks for this PR. You've definitely identified an issue that's been introduced with the raised exceptions on unknown binding types. However, I'm not 100% sold on the solution you've proposed ...
It's always been my intention that the generator will generate/enforce valid Swagger and then filters can be used to extend and enhance the generated document if necessary. Your solution now allows the generator to return invalid Swagger, giving filters an opportunity to correct it. Practically it makes sense, but philosophically it kinda breaks the intended separation of concerns.
Going back to the problem your trying to solve - I think parameters that are bound to services will be automatically ignored because parameters are filtered by Source.IsFromRequest=true. I also think, Swashbuckle should automatically detect CancellationToken parameters and ignore them. I would be happy to add this change.
So, that just leaves the third case you mentioned - parameters with "custom" model binders. These are described as bindings from "unknown data sources" and therefore shouldn't have the IsFromRequest flag because all of the request sources are known as per the HTTP specification. Thoughts?

Personally I was trying to get it working again with the cancellation token.  I have this implemented as a filter and some changes broke it, hence the pull request.
My use case is really just this one at this point.  I added the other types in this PR mostly because they were supported by the enum returned from the framework.
I'm happy to send you another pull request to address just the cancellation token if you can suggest a good place in the code to filter out the cancellation token.  It's a bit messy because the one cancellation token parameter is split into 4 separate fields by the framework, but it have it working cleanly as a filter so it would be easy to reimplement.

Hey I just added handling of the CancellationToken here - bb4f070d4107f3378b2809361338c8dbabd57c29. You're correct - it is a little messy. Maybe my implementation is a little flaky would be interested to see what your filter looks like?

I like your implementation.  It is very clean and elegant.  My filter checked for pretty much exactly the same things you had.
I'll close this pull request for now since it isn't really required anymore.


[ui]: upper jaw inline code string spacing

The following Markdown:
Create a variable called `card_translation` and assign it a translation table to replace all `-` and ` ` characters with an empty string.

Renders as:

There is no space between the ` ` and the proceeding word characters.
There appears to be one in the HTML. So, I assume this is a CSS issue:

@ShaunSHamilton is this still the case and a confirmed bug? If yes, please consider moving it from triage and tagging help wanted as needed.


Hover feature not working on Discord

hi @NateNear , is the discord button not working or just a hower problem

ok thank you for the update will check from my side as well


[clkmgr, util] Change measure_ctrl to shadow types

First commit is #10668, to be rebased away.
Second commit allows shadow registers to be asynchronous.
Last commit changes measure_ctrl to shadow types so the frequency measurements is properly hardened.

For CI, this will need a rebase to get past some change that affected the regtool output (merge skew with changes to usbdev).


Create Soldier and Bananas.cpp

how many pr i can make in your  github account ?
On Fri, 7 Oct 2022 at 13:13, Sunny Raj @.***> wrote:

@.**** requested changes on this pull request.
Please also add the problem link along with your solution.
—
Reply to this email directly, view it on GitHub
https://github.com/SR-Sunny-Raj/Hacktoberfest2022-for-everyone/pull/18#pullrequestreview-1134049594,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AYEEICGI3544IZ7YNIX63STWB7IBZANCNFSM6AAAAAAQ7JHUAY
.
You are receiving this because you authored the thread.Message ID:
<SR-Sunny-Raj/Hacktoberfest2022-for-everyone/pull/18/review/1134049594@
github.com>

You can just make one valid PR in a single repository.


EAS build fails for iOS with Bare Workflow

Build/Submit details page URL
https://expo.dev/accounts/csm-developer/projects/pogo-app/builds/a5be8c95-1167-48d0-810f-d0091780bf34
Summary
The iOS build fails for Expo SDK47.
Managed or bare?
Bare
Environment
expo-env-info 1.0.5 environment info:
System:
OS: macOS 13.2.1
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 16.14.0 - /usr/local/bin/node
Yarn: 1.22.19 - /usr/local/bin/yarn
npm: 8.12.2 - /usr/local/bin/npm
Watchman: 2<IP_ADDRESS> - /usr/local/bin/watchman
Managers:
CocoaPods: 1.11.2 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 22.2, iOS 16.2, macOS 13.1, tvOS 16.1, watchOS 9.1
Android SDK:
API Levels: 31, 33
Build Tools: 30.0.2, 31.0.0, 33.0.0, 33.0.1
System Images: android-30 | Google APIs Intel x86 Atom, android-30 | Google Play Intel x86 Atom
IDEs:
Android Studio: 2021.2 AI-212.5712.43.2112.8815526
Xcode: 14.2/14C18 - /usr/bin/xcodebuild
npmPackages:
@expo/metro-config: ^0.5.2 => 0.5.2
expo: ^47.0.13 => 47.0.13
metro: ^0.66.2 => 0.66.2
react: 18.1.0 => 18.1.0
react-dom: 18.1.0 => 18.1.0
react-native: ^0.70.8 => 0.70.8
react-native-web: ^0.18.12 => 0.18.12
npmGlobalPackages:
eas-cli: 3.5.2
expo-cli: 6.3.2
Expo Workflow: managed
🎉 Didn't find any issues with the project!
Error output
⚠  ld: duplicate method '+moduleName' in
┌─[category]: ExpoBridgeModule-a5938b8bafa3eb034b428d973be07cfa.o ExpoModulesCore/libExpoModulesCore.a
└─[class]: ExpoBridgeModule-674e3c7542e496ffb5e7fcb51e49e14d.o ExpoModulesCore/libExpoModulesCore.a
⚠  ld: method '+UIStatusBarAnimation:' in category from /Users/expo/Library/Developer/Xcode/DerivedData/pogoapp-edbsmuxtvewrvdamrowtwcrdbdwf/Build/Intermediates.noindex/ArchiveIntermediates/pogoapp/BuildProductsPath/Release-iphoneos/React-CoreModules/libReact-CoreModules.a(RCTStatusBarManager.o) conflicts with same method from another category
› Generating debug pogoapp » pogo.app.dSYM
› Executing pogoapp » Bundle React Native code and images
the transform cache was reset.
❌  error: File /Users/expo/Library/Developer/Xcode/DerivedData/pogoapp-edbsmuxtvewrvdamrowtwcrdbdwf/Build/Intermediates.noindex/ArchiveIntermediates/pogoapp/BuildProductsPath/Release-iphoneos/pogo.app/main.jsbundle does not exist. This must be a bug with React Native, please report it here: https://github.com/facebook/react-native/issues
Reproducible demo or steps to reproduce from a blank project
Upgrade bare workflow Expo project to SDK47.

Note: this project started on Expo SDK 40 and has been upgraded SDK's incrementally. So if you'd like to reproduce this issue start on SDK 40 and upgrade to SDK 47. Specifically the upgrade from SDK 46 to SDK 47 the production builds were failing.


Besu + ELK not working on GitPod

Hi,
In GitPod, ELK stack cannot start, with all the other default options, and in any other combination with Hyperledger Besu. The error shown is:
Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting rlimits for ready process: error setting rlimit type 8: operation not permitted: unknown
It is necessary, as documented to execute "sudo chown -R 1000:1000" for both /config/besu and /config/nodes folders, to start the rest of the stack up, but ELK cannot start. With Loki and Splunk no problem (apart from the need for changing ownership).
Enviroment tested in GitPod.
Thanks.
Cheers.

I've personally never used Gitpod before - how much resources are avilable to you on Gitpod? Can you run this on laptop or AWS instance or equivalent?

closing for lack of activity


qview: fix build on darwin, support extra formats

Clarified license to GPL3+.
Building on darwin requires qtsvg.
qtimageformats adds support for extra image formats, such as WebP.
Closes https://github.com/NixOS/nixpkgs/issues/134210 (cc @Jiehong)

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

@ofborg eval


Update README.md(hacktoberfest)

@nicolasnoble

Please note that this is a spam PR and is against the rules of Hacktoberfest.


Close kgio socket after IO.select timeouts

Hello,
I had a trouble that my web application processes stil holds established TCP connections with remote Memcached servers after one Dalli::Server downs and RingError occurs.
I tried some times and found that when Dalli::Server::KSocket#kgio_wait_writable fails with Timeout::Error, the created sockets are left and survives after the error.
This patch worked well in my environment.
Though I tried only for TCP socket, I think this patch is applicable for UNIX socket, too.
Thanks,

@key-amb This PR seems pretty safe, but it touches low level code.  Do you see any potential issues?

@petergoldstein
Thank you for taking a look.
I think this patch is quite safe, too.
I don't see any potential issue about this.
This patch works well in my environment for weeks.


Feature request: atom feeds

Feature: every thread has its own .ATOM feed (XML document containing a list of entries composed of name, date, url, post body). Every board has an .ATOM feed for new threads.
Rationale: this makes it easy for users of slower boards (those seeing under 100 posts per week) to see updates as they come in, or to see responses to interesting threads through the use of existing software by the means of a simple and well-documented standard. These are beneficial for moderators as well (they can receive a notification as new threads are made) and for users of larger boards (who can follow their favorite threads more easily).
ATOM entry

<entry>
<title> Reply #num in thread $title </title>
<id> //posturl/thread#postnum</id>
<updated>ISO8601-formatted post date & time</updated>
<author><name>Anonymous / post's author</name></author>
<content type="html">
The post's content, suitable for viewing in an ATOM feed reader
</content>
</entry>

also for trip meta pages

The atom/rss feeds should be cacheable. Just JSONify objects.


Proposal: Unit type checking

(DO NOT MERGE)
This is a demo PR to illustrate how unit type checking might work (see #3309). If Squiggle maintainers like my proposal, I can finish implementing it. I'm also fine with tabling this PR if maintainers think it would take too long to agree on a good implementation. I do think it would be really nice to have unit typing, it could prevent a lot of bugs.
This PR is only a demo, it has various missing parts and the code quality isn't consistent. See "Open questions" below.
Syntax
Squiggle unit types are declared using approximately the same syntax as TypeScript. Example:
x = 1  // implicit type
y: kg = 1  // type is `kg`

A type signature consists of one or more identifiers separated by zero or more * symbols, followed by zero or more identifiers separated by zero or more / symbols. In other words, type signatures must match the pseudo-regex \identifier(*\identifier)*(/\identifier)*.
Some more examples of type signatures:
speed: m/s = 1
force: kg*m/s/s = 2
work: kg*m*m/s/s = 3

Semantics
The parser type-checks variable definitions and expressions.
For this demo, the type checking rules are fairly simple:

Any variable without a declared type is simply assumed to be the correct type, even if that's not logically possible.
An expression that multiplies or divides two variables with known types infers the type of the result. For example, if x has type kg and y has type liter, x/y has type kg/liter.
If two values with known types are combined using an infix operator other than * or /, the type checker enforces that the two values have the same type. For example, you can only add/subtract two variables if they have the same type (or if at least one of them does not have a declared type).
If a typed variable is assigned to a value with a known type, the type checker enforces that the value has the correct type, and raises a type error if not.

Implementation details
I implemented type checking in the way that looked best to me, but Squiggle maintainers may have a better idea of how to do it.
In parse.ts:parse(), after generating the AST, I added a call to the typeCheck() function, which is defined in a new file typeChecker.ts.
Open questions
There's definitely more that needs to be implemented to make this PR viable, but I didn't want to make too many design decisions without consulting the Squiggle team.

Should the type checker do type inference, or should it simply ignore any variable without a type (like TypeScript's any)? Type inference is more work but it looks doable to me. But it's not obvious that type inference is actually desirable from a design standpoint. (I lean toward yes.)
How to treat numeric literals? I see two reasonable possibilities: (1) let them be any type, or (2) treat them as unitless unless directly assigned to a variable (e.g. in x: kg = 1, the 1 should be treated as having type kg, not unitless). Treating them as unitless would help catch more type errors, but it also means you'd need a syntax for type conversion. For example, if you have a distance literal and a time variable, converting them to velocity requires declaring the type of the literal, such as usainBoltSpeed: m/s = (100 as m) / raceTime.
Is my proposed syntax ok? There are ways it might be improved, for example allowing parentheses and/or exponents:
work: (kg*m^2)/(s^2) = 1
Do probability distributions require any special treatment? I believe they can be treated just like numeric values.
What syntax should function definitions use? I'm thinking it could use basically the same syntax as TypeScript:
func(x: type): type = ...
How to type arrays and dicts? Should Squiggle require that the values in an array/dict all have the same type? What should the type signature syntax be? Again, it can probably be the same as TypeScript.
It would be good for SquiggleHub to have a good way of showing types. How should squiggle-lang  supply type info make that work? (SquiggleHub does some stuff with GraphQL that I don't understand but I haven't looked into it much.)
How to handle type errors? Should they be a subclass of ICompileError, or should they be handled separately? Does the frontend need some special way to consume them?

Quick comment based on the overall idea, I haven't looked at the implementation carefully yet.
Thanks for doing this! This is definitely something we discussed and want to support.
My main problem with the syntax that you picked is that besides unit type checking, we'll also want to implement other type checks in the future.
For this reason I'd strongly prefer if we used something else than : to provide the unit portion of the type.
This is easy to fix if we go with :: instead of :, for now:
speed :: m/s = 1

The design for actual types (that would allow to express other value types, e.g. functions or lists or whatever) is still not finalized and will probably take a while, but note that we already have annotations in function signatures.
Units are obviously not types, because:

they can't express any types other than numbers
their names are too free-form, so you can't refer to type or variable names in type signatures

Btw, this is tangential, but my current plan is to eventually support domains everywhere:

domains are values (can be constructed in runtime) that can be used in type signatures
domains are generics from which compile-time types can be inferred
domains also do runtime checks when compile-time checks are too difficult
we could also have syntax sugar because full domain definitions are too clunky; similar to how in function signatures we already upgrade [5, 10] to Number.rangeDomain(5, 10); units could also be extended in the similar way, x :: m/s -> x: Number.unit("m") / Number.unit("s")

With domains, we could start with completely runtime type-checks and gradually push the boundary towards compile-time checks where it's possible; but it won't be possible in all cases.
This also means that for now I don't really care if unit type checking or any other type checking is done in the compile-time. It's fine to prototype type checking in runtime, and then optimize later (if we pay attention and avoid features that are too powerful and can't be optimized later).

Now on these questions:

Should the type checker do type inference, or should it simply ignore any variable without a type (like TypeScript's any)? Type inference is more work but it looks doable to me. But it's not obvious that type inference is actually desirable from a design standpoint. (I lean toward yes.)

Type inference sounds very useful, and as I said above, its lack is dangerous because of backward compatibility problems.
I'm leaning towards "let's just infer in runtime", though.

How to treat numeric literals? I see two reasonable possibilities: (1) let them be any type, or (2) treat them as unitless unless directly assigned to a variable (e.g. in x: kg = 1, the 1 should be treated as having type kg, not unitless). Treating them as unitless would help catch more type errors, but it also means you'd need a syntax for type conversion. For example, if you have a distance literal and a time variable, converting them to velocity requires declaring the type of the literal, such as usainBoltSpeed: m/s = (100 as m) / raceTime.

Is my proposed syntax ok? There are ways it might be improved, for example allowing parentheses and/or exponents:
work: (kg*m^2)/(s^2) = 1

It's fine if we don't support these for now.

Do probability distributions require any special treatment? I believe they can be treated just like numeric values.

I'm not sure. I think units syntax is fine for dists if we store types separately (x : type :: units = ..., as I said in my previous comment), but I haven't thought about this too much.

What syntax should function definitions use? I'm thinking it could use basically the same syntax as TypeScript:
func(x: type): type = ...
How to type arrays and dicts? Should Squiggle require that the values in an array/dict all have the same type? What should the type signature syntax be? Again, it can probably be the same as TypeScript.

I don't consider units to be full types, and doing both at the time would be too complicated; see my comment on domains above.

It would be good for SquiggleHub to have a good way of showing types. How should squiggle-lang supply type info make that work? (SquiggleHub does some stuff with GraphQL that I don't understand but I haven't looked into it much.)

GraphQL doesn't seem relevant here; runtime inference based on tags would be very helpful.

How to handle type errors? Should they be a subclass of ICompileError, or should they be handled separately? Does the frontend need some special way to consume them?

ICompileError seems fine for this, can be improved later. But, again, if we do runtime inference, then it's going to be just a normal runtime error, for now.

@berekuk Based on your comments, here's my to-do list. Let me know if I should add anything.

Update unit type syntax to not conflict with (future) normal type syntax.
Implement type inference.
Treat numeric literals as any unit type. (Note: This will create backward compatibility issues if we decide later to make literals unitless.)
Add unit type syntax to the prettier plugin.
Unit type checking on distributions.
Minor fixes e.g. delete unused code.

Also: Can you explain what you mean by "domain"? And relatedly, why do you think it's too complicated to do unit types for function definitions and arrays/dicts?

Update unit type syntax to not conflict with (future) normal type syntax.
Implement type inference.

I think that tracking unit info in runtime, through tags, would be easier for now, and would give us same benefits as full type inference at the cost of a slight performance overhead. But either approach is fine, and we'll want compile-time type checks and inference eventually. I just think it's more work for you.
Full type inference is especially tough, so I'll explain my priorities for it:

some solution for units in nested blocks is a blocker for merging this PR (worst case scenario, just ban unit syntax in blocks entirely)
type inference on trivial assignments and arithmetic operations is also nice for the future backward compatibility, but I would agree to merge if (1) is fixed
type inference on generic functions is

For clarity, in (1), I mean this:
x = {
  y :: kg = 1
  z :: m = y
  y + z
}

This would be quite unexpected for users, the feature looks like it should work but it doesn't do anything, and it's a footgun.
In (2) I mean this:
x :: kg = 1
y = x

And this:
x :: m = 1
y :: s = 2
z = x / y    /* m/s? */

And in (3) I mean this:
f(a) = a
x :: kg = 1
y = f(x)

This one is the most difficult, and you definitely shouldn't attempt it now; some languages (Haskell and OCaml) are smart enough to infer that f maps any generic 'a to 'a, so it would infer that y has the same type as x. But this would require something like full Hindley–Milner.
Or, you could get all of (1), (2) and (3) for free, and also easier access to the unit information during render, if we do runtime tracking with tags.

Also: Can you explain what you mean by "domain"?

The term "domain" is briefly mentioned in the parameter annotation documentation, but not very well explained.
The idea is that any check ("is this a valid value to use here?") can include runtime checks ("does the value belong to the [10, 20] range?") and compile-time checks ("is this a number?"). We plan to bundle both of these checks in a single "domain": a meta-value that describes both components.
Unlike in Typescript, domains are values, not a separate namespace of "type names". They can be constructed in runtime, e.g. with functions, passed around as parameters, and so on.
xDomain = Number.rangeDomain({ min: 5, max: 10 })
x: xDomain = 7

Here, xDomain type would be, let's say, Domain<Number>, and when you annotate x: xDomain, Squiggle would infer that x type would be Number. So it would do the compile-time check that x is a number, by checking that 7 is also a number.
In addition to that, Squiggle would also do the runtime check to make sure that 7 is in [5, 10] range.
The currently supported f(x: [5, 10]) = ... syntax for parameters annotation is a syntax sugar on top of domains: [5, 10] annotation used after : gets upgraded to the domain. This would work in the same way for variable declarations, x: [5, 10] = 7.
We will support other annotation shortcuts in the future, because full domain constructors are too verbose. Also, common types will also become domain constructors, e.g. x: Number = 7. Number is a function, but the "annotation -> domain" syntax sugar layer will upgrade it to the domain, so it's the same as, let's say, Number.anyValueDomain().
This is the very preliminary plan for the future type system in Squiggle. It's going to be somewhat complicated to implement, because it's heavy on generics, but it seems doable. I'm not sure when we'll get around to implementing all this, tbh.

Come to think of it, I don't think runtime type checking works for type inference. For example, consider
dist = 5
otherDist = 3
velocity :: m/s = dist / otherDist
x :: m = dist + otherDist

Line 3 does not strictly enforce types on dist and otherDist so it doesn't complain. Line 4 enforces that dist and otherDist both have type m, which contradicts line 3, but line 3 already ran so the unit type checker doesn't complain.

For blocks, should it be allowed to re-define a variable inside a block with a new unit type? For example,
x :: kg = 1
{
  x :: lbs = 2
  x
}

This seems more logical given how block scoping rules work, but it could be confusing in some situations, for example:
x :: kg = 2.2
y :: lbs = 1
{
  x = y
}

You might expect this to raise a type error but it doesn't, because the x inside the block is considered distinct from the outer x.

I already implemented backward unit type inference so it looks like it works (but there could be edge cases I haven't thought of). The way it works is by making a list of constraints, for example
x :: kg = 1
y :: lbs = x

produces the list
x^1 = kg^1
y^1 = lbs^1
y^1 = x^1

If you take the logarithm of each of these, you get a system of linear equations, which you can solve using Gaussian elimination (which runs in approximately O(n^3)). In this case, the solution will look something like
x = kg
y = lbs
0 = lbs / kg

The third line is nonsensical which means there's a type error (and you can tell where the type error is by looking at which step in the Gaussian elimination algorithm produced the invalid line).

For blocks, should it be allowed to re-define a variable inside a block with a new unit type?

Yes, I think both examples you give should be allowed.
Even this should be allowed, because Squiggle doesn't have mutable variables, any new declaration is shadowing:
x :: kg = 1
x :: lbs = 2

(btw something like this is also allowed in Rust, so it's not that unusual)

If you take the logarithm of each of these, you get a system of linear equations, which you can solve using Gaussian elimination (which runs in approximately O(n^3)).

Huh.

it's impressive that you did this
but I'm still skeptical that it's practical

The examples you give in your last comment are for the simpler case where the entire expression consists of divisions and multiplications.
But in practice you'll also have addition and subtraction (and also other operations and builtin functions); and those seems to map to something SAT-shaped, in general case?
Also, this particular puzzle with unit types is a very special case of a more generic longer-term goal of having type inference in general, and it feels very weird to have it so overpowered for units and underpowered for everything else; it's also hard to predict right now how unit types with backward inference will interact with other type inference steps, the approaches will get in conflict at some point, and so the cost of maintenance of complex solutions seems too high to me.

Even this should be allowed, because Squiggle doesn't have mutable variables, any new declaration is shadowing:

Ok, I didn't realize this, re-declarations don't work with my current implementation. But I was going to have to change it to make blocks work anyway so I'll change this too.

But in practice you'll also have addition and subtraction (and also other operations and builtin functions); and those seems to map to something SAT-shaped, in general case?

+, -, ==`, etc. require that the two arguments have the same unit type. This is a pretty easy constraint to check. I've already implemented backward type inference for all (valid[1]) binary operations and it works. From looking thru the list of builtins, I think it should work, but I haven't looked at them in detail.
[1] Some binary operations, like &&, don't produce unit types. ^ only produces a unit type if the exponent is an integer literal so I just let the result of ^ be any type (I could change this later).

Also, this particular puzzle with unit types is a very special case of a more generic longer-term goal of having type inference in general, and it feels very weird to have it so overpowered for units and underpowered for everything else; it's also hard to predict right now how unit types with backward inference will interact with other type inference steps, the approaches will get in conflict at some point, and so the cost of maintenance of complex solutions seems too high to me.

Wouldn't unit types and normal types be totally separate systems? Although I can see that it's a weird UX if inference works differently for types vs. unit types.
If it's not too much trouble, could you write a few test cases that you expect would fail for backward type inference? I am writing my own test cases but since you're more knowledgeable, you can probably come up with more edge cases than me. If backward type inference turns out not to work, or if we decide forward inference is better UX, then it shouldn't be hard for me to rewrite it to do forward inference only.

Type checking and backward inference now work (according to my test suite) for blocks. I'm not sure I understand Squiggle's scoping rules but I believe the type checker behaves correctly according to the scoping rules.

I have an idea for how to do type inference on generic functions, I haven't implemented it yet but I believe it will work. Should there also be syntax for explicit generics?
It's not obvious how to do syntax for generic functions because a unit type can be any identifier. A few ideas:

generic types are numbers: f(x :: 1, y :: meters) :: 1 = { ... }
generic types are capitalized words: f(x :: Any, y :: meters) :: Any = { ... }
generic types are indicated by some kind of syntactical marker, for example square brackets: f(x :: [any], y :: meters) :: [any] = { ... }

BTW my plan is to fully implement backward inference to check that it works, but if you prefer forward-only inference (because it's easier to maintain, or better UX, or whatever), it shouldn't be too hard for me to rewrite to do forward-only inference.

Having investigated more, it looks like it's difficult to do compile-time type checking for functions whose values get determined at runtime, such as higher-order functions:
apply(f, x) = f(x)
double(x) = 2*x
x :: meters = 2
y = apply(double, x)

It's theoretically doable but it would take quite a bit of work.
I can see a few ways of implementing unit type checking that avoid this complexity:

Do function type checking on a "best-effort" basis: the type checker checks functions when it can, but for functions whose values aren't known at compile time, it just assumes the types are correct.
Type check at compile time when possible, and type check everything else at runtime.
Type check everything at runtime.

I think number 1 is reasonable because type checking on non-static functions is pretty niche so I doubt many people will miss it. But number 3 is perhaps clearer.

Hi Michael! Sorry for the slow response, I was occupied with finishing another big PR.
I'll address the meta first; I realize that communication on this is complicated because:

I don't know much about your background so I don't know if you have experience with advanced strong-typed languages such as OCaml or Haskell; but my impression is that you're mostly trying to figure it out as you proceed, in ad-hoc fashion
at the same time, I'm very far from being an expert myself! I know some things, but could easily be wrong about some stuff, and the possible skill ceiling on type system knowledge seems extremely high
I think some amount of ad-hoc approach in this is fine and unavoidable, but it's also easy to paint yourself into the corner because some early feature (like backward inference) will block future features due to implementation complexity or computational complexity, so it's good to have some foresight into what's easy here and what's hard

On backward inference, I've realized there's a trivial example that shows that it's not doable in general:
x = 1
y = 2
z :: kg * m = x * y

So, x :: kg; y :: m or x :: m; y :: kg? No way to know.
(I believe this is a very simple example of a much more complicated problem; when you have backward inference and also other features such as functions and generics

Hi Michael! Sorry for the slow response, I was occupied with finishing another big PR.
I'll address the meta first; I realize that communication on this is complicated because:

I don't know much about your background so I don't know if you have experience with advanced strong-typed languages such as OCaml or Haskell; but my impression is that you're mostly trying to figure it out as you proceed, in ad-hoc fashion
at the same time, I'm very far from being an expert myself! I know some things, but could easily be wrong about some stuff, and the possible skill ceiling on type system knowledge seems extremely high
I think some amount of ad-hoc approach in this is fine and unavoidable, but it's also easy to paint yourself into the corner because some early feature (like backward inference) will block future features due to implementation complexity or computational complexity, so it's good to have some foresight into what's easy here and what's hard

On backward inference, I've realized there's a trivial example that shows that it's not doable in general:
x = 1
y = 2
z :: kg * m = x * y

So, x :: kg; y :: m or x :: m; y :: kg? No way to know.
(I believe this is a very simple example of a much more complicated problem; when you have backward inference and also other features such as functions and generics

Hi Michael! Sorry for the slow response, I was busy with finishing another big PR.
I'll address the meta first; I realize that communication on this is complicated because:

I don't know much about your background so I don't know if you have the experience with advanced strong-typed languages such as OCaml or Haskell; but my impression is that you're mostly trying to figure it out as you proceed, in ad-hoc fashion
at the same time, I'm very far from being an expert myself! I know some things, but could easily be wrong about some stuff, and the possible skill ceiling on the type system knowledge seems extremely high
I think some amount of ad-hoc approach in this is fine and unavoidable, but it's also easy to paint yourself into the corner because some early feature (like backward inference) will block future features due to implementation complexity or computational complexity, so it's good to have some foresight into what's easy here and what's hard

On backward inference, I've realized there's a trivial example that shows that it's not doable in general:
x = 1
y = 2
z :: kg * m = x * y

So, x :: kg; y :: m or x :: m; y :: kg? No way to know.
I haven't figured out your implementation yet, maybe you're doing backward inference only when one of parameters is untyped? Or does this result in error because there's not enough information?
Either way, I believe this is a very simple example of a much more complicated problem; when you have backward inference and also other features such as functions and generics, the complexity will blow up.

Another evidence against backward inference is that I can't think of any language that has it.
I think Prolog kinda does, but not on type system level?
And OCaml/Haskell have powerful type inference that can look like backward inference but it's not exactly that (I'll address this in the next section.)

Now, on generic functions. There's a long ladder of power that starts with "no types" and ends with "theorem provers", with several steps in between:

weakly typed languages — everything is checked at runtime
everything up to TypeScript and below — if args are not typed then return values are also not typed; f(x) = x always returns any
OCaml level, i.e. Hindley-Milner — types are inferred based on operations done in function definition, even if parameters are not typed. Here's Rescript example. This level is very cool, but unfortunately "Attempts to combine subtyping and type inference have caused quite some frustration.", and I'm pretty sure we'll need subtyping in Squiggle.
Languages that support dependent types. These can do anything, at the cost of performance and cognitive load for your users. Squiggle will never get to this stage.

Btw, it's not like Hindley-Milner is complicated; the math in wikipedia page or other common explanations may look complicated if you don't know the syntax, but I have this gist bookmarked, it implements it in ~200 lines of code. The question is more of: should we do it?
RIght now Squiggle is at (1), and we aim to get it to (2) or (3), but my understanding is that subtyping vs type inference tradeoff is key here and it's not trivial. The detailed explanation would take too long (this comment is already too long), so I'll write a dense outline of my thoughts on this and hope that it'll be at least somewhat understandable:

you can either do subtypes or algebraic data types, but you need one of these
Squiggle doesn't have custom structs so users pass dicts around and sometimes you'll want to add or remove or transform a dict; similar to TypeScript, a good type engine should infer transformation shapes; this is "subtyping"
we could add structs, but albegraic data types (GADTs) are more clunky/more formal, e.g. you'll need Option types and unwrap things manually, and it's not clear that it's worth it in a language designed to be easy-to-use for quick sketches
so I guess we'll have to do (2)? but I've been postponing this decision until we introduce custom structs because then it'll be more clear how far we can push this boundary, type inference in polymorphic functions is really nice when you have it, maybe some partial version of it is doable?

Anyway, my advice for now (unless you know something that I don't, which is very possible, again, I'm very much not an expert here and can be confused):

drop backward inference
do the easiest thing possible with inferring units, I don't care if it's runtime or compile-time
don't infer return types in functions for now, if you do compile-time; syntax for explicitly marking the return value with units is fine but also optional

On my background:

I'm fairly familiar with Haskell, I've written maybe 10,000 lines of code in it. Not familiar with OCaml.
I've written two different compilers for toy languages, one of which was statically typed (it was object-oriented, not algebraic types).

I'm figuring out unit types as I go because unit types differ from normal types in some important ways:

you can use a unit type at any time without defining it (you can say x :: kg = 1 without ever defining what a kg is)
unit types don't have internal structures the way objects or algebraic types do
unit types don't have typeclasses
not every value has to have a unit type

It doesn't really make sense to do Hindley-Milner for unit types because there is no such thing as a unit typeclass. (I suppose we could implement unit typeclasses but I don't see much point.) And the complexity of type inference mainly comes from (1) typeclasses and (2) higher-order functions, so if you don't have typeclasses, that makes things simpler. (Higher-order functions are still hard.)
I did look a bit for pre-existing work on how to implement unit types and some work exists but there's no established best practice.

you can either do subtypes or algebraic data types, but you need one of these

Can you explain your reasoning? I wouldn't think you'd want either of those for unit types.
As to your backward inference example—you're right that there are some other situations where backward inference is hard, but this sort of case isn't a problem:
x = 1
y = 2
z :: kg * m = x * y

The unit type system imposes a constraint that x * y must have type kg * m, but it has a degree of freedom, so in the absence of any other constraints, x and y have unspecified unit types and there is no error.
As of my latest commit:

Implicitly-typed generic functions work (at least my tests pass, there might be edge cases I haven't found).
Explicitly-typed functions work.
Backward inference works.

However:

There is no syntax for explicitly-typed generic functions.
Type inference for functions only works when the function's value is known at compile time. For example, the type checker can't infer types on this: y = (condition ? f : g)(x). I have a vague idea of how to fix this but it would require significant rewrites. Right now the type checker just ignores functions whose values aren't known at compile time.

My previous two comments described an implementation that does 'function type checking on a "best-effort" basis', which I have now implemented.
"the easiest thing possible with inferring units" would be backward type inference for functions and variables but excluding functions whose values aren't known at compile time, because I've already implemented that.
If you expect the unit type checker to stumble in certain situations, I think the most helpful thing would be for you to write Squiggle code that you expect to cause issues, and I can turn that code into unit tests. You might also have a look at the tests I've already written, especially the ones starting from this line.

On my background:

Thanks for clarifying!

It doesn't really make sense to do Hindley-Milner for unit types because there is no such thing as a unit typeclass.
[...]
Can you explain your reasoning? I wouldn't think you'd want either of those for unit types.

I missed an important assumption that I'm making: I mostly wasn't talking about unit types, but about type checking for Squiggle in general, because unit types are just a part of that.
Here's the argument:

unit types are going to be the innermost type parameter of generics, because we'll eventually have arrays of unit-marked numbers, tuples, distributions over units and so on
with type inference for types in general, types for expressions that are far away from each other can be connected by type inference
if those types can be generics over units, then by adding features for units, you're also kind of precommitting to support those features for containers-over-units, which is a much more complicated task, which will require you eventually to pierce through all layers of wrapped high-order types to connect the information about units across the entire type graph

I should look at your implementation more carefully, but for now I'm very hesitant because of these future maintenance costs when we eventually try to combine backward inference with generic container types.

Another thing that makes me not very excited about backward inference, tbh, is that it just... doesn't seem very useful?
Like, it's clear why forward inference is useful.
And it's clear why ML-style generic functions or typeclasses are useful, e.g. being able to infer f(x) = x; f(1) /* number */ without manually writing out generics for f.
But backward inference for units is neither of that, and in most cases I can think of you will have to name the unit somewhere, and you might as well do it at the first variable. AFAICT you won't save any keystrokes through inference here?

One more problem with backward inference is that O(N^3) is kinda slow. Squiggle has to be real-time (by default we recompile and run the code on each keystroke!). I'm not sure if the slowdown will become noticeable around 30 statements or around 100; 100 doesn't seem so bad, but if it's closer to ~30 statements then it's a problem.

I mostly wasn't talking about unit types, but about type checking for Squiggle in general, because unit types are just a part of that.

I see. I was thinking of unit types and normal types as separate things. My thinking was that

unit types are more useful than normal types for Squiggle's applications (quantitative models etc.)
unit types only make sense for numbers (and number-y types like symbolic dists) so there's no need to make unit types well-defined for all types (strings, etc.)
unit types don't work the same way as types, for example multiplication preserves type but changes unit type

But if unit types are a subsystem within the general type system, then that makes things more complicated, as you say.
In that case, this PR seems problematic because it encodes a bunch of decisions about the unit type system that the general type system will have to adopt, but I haven't put any thought into whether the design makes sense for a general type system—at a glance, I don't think it does.
At least for how I use Squiggle, unit type checking is much more useful than general type checking so I'd like to see it deployed first, but I wouldn't want to deploy it in a way that could mess things up later down the road. But that makes me think the type system needs to be fully specced out before unit types can be implemented.
If you have a general picture of how types will work, and you can see a way to implement unit types that won't be a problem in the future, I'm happy to implement it. It sounds like you're ok with either (1) compile-time checking with forward inference or (2) run-time checking, but you don't think backward inference will work with general types. I agree, I don't think it will work—it works fine for unit types but then you can't interlock the two type systems.
I'm not sure how to proceed—I want Squiggle to have unit types and I'm happy to implement them, but I don't think I'm qualified to make design decisions about how the general type system should work, since I don't have the broad perspective on Squiggle's design philosophy that you have. I'm sure you're working on lots of other stuff so I don't want to push more work onto you.
If you think my current design will work other than the backward inference, it wouldn't be hard for me to rewrite it to do forward-only inference.

The current design only allows unit-type-checking on statically-defined functions, which could be an issue, and I don't think compile-time checking will work at all for arrays/dicts because right now arrays/dict elements can contain any arbitrary types, so it's impossible to know what they contain at compile time. The type checker would probably need to do something like TypeScript where you can enforce types on particular data structures, but untyped data structures can contain anything.

If unit types are supposed to be a part of the general type system, the syntax I chose might not be ideal, but changing the syntax is pretty easy and doesn't affect the type checking logic at all. I had imagined that the syntax would look like
explicitUnitType :: kg = 1
explicitNormalType : float = 2
explicitBothKindsOfTypes : float :: kg = 3

But perhaps it would make more sense to do something like
explicitUnitType : any[kg] = 1
explicitNormalType : float = 2
explicitBothKindsOfTypes : float[kg] = 3

One more problem with backward inference is that O(N^3) is kinda slow.

I just did a quick performance test. With 100 variables it runs ~instantly (a normal test with a few variables takes 0.5 sec, a test with 100 variables also takes 0.5 sec). With 1000 variables it takes 29 sec. With 200 variables it takes 1 sec (so 0.5 sec after the test setup).
I would also note that the reason it's O(n^3) is because it can infer arbitrarily complicated unit type relationships. For example:
a = 0
b = 1
c = 2
x :: m/s = a / b
y :: kg/s = b / c
z :: kg/m = c / a

Any two of (x, y, z) don't conflict, but all three together create a type error.
There's a simpler version of the type checker that can only find conflicts between pairs of variables (so it would fail to find the type error above), and I think that's doable in O(n^2). Admittedly the above example is a pretty weird situation that will likely hardly ever come up in real code.

In that case, this PR seems problematic because it encodes a bunch of decisions about the unit type system that the general type system will have to adopt, but I haven't put any thought into whether the design makes sense for a general type system—at a glance, I don't think it does.

Yep! Happy to know we're on the same page now.

At least for how I use Squiggle, unit type checking is much more useful than general type checking so I'd like to see it deployed first

I don't mind doing things in whatever order.
For me, general type checking is mostly useful for editor features — autocompletion and so on. Especially with how -> operator works, it's nice to hint the allowed methods; also myDict.foo autocompletion would be very nice.
Potentially also performance gains, but that will be harder to achieve.

If you have a general picture of how types will work, and you can see a way to implement unit types that won't be a problem in the future, I'm happy to implement it. It sounds like you're ok with either (1) compile-time checking with forward inference or (2) run-time checking, but you don't think backward inference will work with general types. I agree, I don't think it will work—it works fine for unit types but then you can't interlock the two type systems.

Full type system is definitely out of scope of this PR, and even discussing it would take too long now, so the question is how to finish units without creating future problems.
Yes, I'm fine with either (1) or (2).

The current design only allows unit-type-checking on statically-defined functions, which could be an issue, and I don't think compile-time checking will work at all for arrays/dicts because right now arrays/dict elements can contain any arbitrary types, so it's impossible to know what they contain at compile time. The type checker would probably need to do something like TypeScript where you can enforce types on particular data structures, but untyped data structures can contain anything.

Yeah, even when Squiggle gets types and generic types, it will still have to be gradual typing and not fully statically inferred. But I think it's fine if we don't worry about that for now.
I also won't mind if this PR ended up not supporting functions at all! Happy to merge even if only basic cases such as x :: kg = 1; y = x or x :: kg = 1; y :: t = 2; z = x / y are supported.

I had imagined that the syntax would look like
explicitBothKindsOfTypes : float :: kg = 3

But perhaps it would make more sense to do something like
explicitBothKindsOfTypes : float[kg] = 3

I hope to start with the former and end up with the latter. Then we deprecate :: in the future release; this is why I suggested ::, to reserve : for this future gradual upgrade.

Ok, I think I know what to do with this PR then. I will rewrite it do to forward-only compile-time unit type inference. There's a good amount of outstanding work beyond that, on things like updating the prettier plugin and writing docs, which I will get to next.
My biggest open questions right now are:

[ ] Right now the type checker throws a compile error when it finds a type error, but it can only throw one error at a time, and the type checker can find all errors simultaneously. Is there some better way of raising errors so the user can see all of them at once?
[ ] For this PR, do we want Squigglehub to have some UI for displaying unit types and type errors? Or should that be separate? (Might be better to do it separately so this PR doesn't get too big.)
[ ] Squiggle already uses the word "unit" to refer to multiplicative suffixes, like how "100k" means 100,000. Is it bad if "unit" also refers to unit types? Should they be called something else?

A couple more notes:

[ ] Right now, all built-in functions are treated as taking and returning any type. It looked like too much work to add type annotations to each of the hundreds of built-in functions. But that means if we do add type annotations in the future, it won't be backward-compatible.
[ ] I was thinking about it and I realized that downgrading from backward type inference to forward-only is a non-breaking change, but adding backward type inference is a breaking change. I rewrote the type inferrer to be simpler but it can still (sometimes) do backward type inference. It's easy to change to do forward-only inference—it only requires deleting a single line of code.

This PR is complete and ready for review, other than the concerns raised in my last two comments. There are still plenty of missing features (as we've discussed already) but I don't think they're necessary for an MVP unit-type system.
I plan to write another PR to implement a display on Squigglehub that shows variables' inferred unit types.

As we discussed in Discord, I've merged this without going into too many details in the review, because:

tests are passing
AFAICT this feature doesn't break any existing code
in the next few days I plan to start on the full-blown semantic analysis layer for Squiggle, which implies significant further changes to this code

Thank you for doing this PR, I believe it's the most substantial open-source contribution we've had to Squiggle, by far!


Basic proxy authentication

I run CS on my local host and qbit on a remote seedbox that requires proxy authentication when accessing via https.
When I ty to set the qbit url  in the config to https://user:pass@domain/qbittorrent I'm getting a qbit login error.
qBittorrent login failed with code 401
Would it be possible to support proxy authentication so https can be used when accessing remote clients?

If I'm not mistaken, this is something that could be easily accomplished with a reverse proxy setup such as nginx or caddy (just two popular options of many choices)

nginx in my case

nginx in my case

https://shairosenfeld.blogspot.com/search?q=nginx would seem relevant perhaps, just a quick search.

I was hoping for a fix where I don't have to mess with NGINX on the seedbox, managed that for all other apps, CS is the only one that I haven't managed to get https working for.
I'm terrified to lock myself out.
And that won't be a solution for users on a shared box, they won't have root access and probably can't access the NGINX settings.

I was hoping for a fix where I don't have to mess with NGINX on the seedbox, managed that for all other apps, CS is the only one that I haven't managed to get https working for. I'm terrified to lock myself out. And that won't be a solution for users on a shared box, they won't have root access and probably can't access the NGINX settings.

Did you ever get this to work? I am having the exact same problem


Support embedded JavaScript in HTML

I have an html page with embedded javascript in a script tag. Can I debug this with the extension also?

At this point in time none of our VS Code JavaScript debuggers supports inline JS.

:( What would be a possible workaround?`Separating the js?

Yes, it would be to put the script it's own .js file and include it. It needs to be a file you can open independently in your editor.


Dark Mode

Can you, please add dark mode.

Check out an already open issue regarding dark mode: https://github.com/a1xd/rawaccel/issues/144.


Fix for parse_directory ignoring unknown entries

Pull Request Checklist:

[ ] pre-commit hooks are installed/active in my local clone ($ pre-commit install)
[ ] This PR addresses an already opened issue (for bug fixes / features)

This PR fixes #xyz

[ ] (If applicable) Documentation has been added / updated (for bug fixes / features)
[ ] If a merge request has been made in parallel to this PR in xscen-notebooks, it is merged and the submodules have been updated.
[ ] HISTORY.rst has been updated (with summary of main changes)

[ ] Link to issue (:issue:number) and pull request (:pull:number) has been added

What kind of change does this PR introduce?

If there are entries in patterns that are unknown to xscen (e.g. 'hydro_calibration'), parse_directory will ignore them. This fixes it.

Does this PR introduce a breaking change?
Other information:

Don't worry about this PR. After discussion, we'll wait until Pascal comes back and integrate the charges (if still warranted) to his PR.


[React Components] Refresh the page after Sign In / Sign Out

Refresh the page and redirect users back to the main storefront once they sign out.
Description
I added the baseUrl(Storefront URL) in the App configs, and in the event handler for signing out, we redirect the user to the main storefront once they click 'Sign Out'. The baseUrl is configured based on the main storefront url(Storefront can be any language/country, not always US and English).
Related Issue

Motivation and Context
If users are in any admin pages(Address book, account management), once they sign out we want them to be redirected back to the main storefront. Currently, we revoke the user token and reset cookies as well as the contexts, but no refresh/redirect takes place.
How Has This Been Tested?
This has been tested in the two sign out user cases.

Signing out from the main navigation. Once we click 'sign out', no matter which page we're in(Catalog, address book, etc), we're taken back to the storefront.

Same thing happens when signing out from the account panel in responsive mode.

Screenshots (if appropriate):
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have signed the Adobe Open Source CLA.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes and the overall coverage did not decrease.
[ ] All unit tests pass on CircleCi.
[x] I ran all tests locally and they pass.

I think this PR should be filed against the dev branch...


prints for every shell command

Hi !
I installed and used successfully the master branch of ssh-ident (it's very neat ! It would be cool to have the README formatted though). I set up aliases for ssh and git.
But now, for every shell command I run (cd, ls,…) ssh-ident prints some output:
Agent for identity vindarel ready
All keys already loaded
Agent for identity vindarel ready
debug ssh-ident: using identity vindarel
All keys already loaded

Sure, I can comment out those lines in the code, but I'd like them to show up when I run =ssh= or =git= (only). And it doesn't seem right that ssh-ident is called everytime… An idea ? (I use zsh)
Thanks !

I believe, making git an alias to ssh-ident is not a good idea. ssh-ident will try to load keys for every git command, even if it does not require SSH (e.g. because it operates on the local repo only, all remotes are https, ...). Having a symlink named ssh in the $PATH works much better in this regard.
However, I would like to back up the feature request for a "quiet" option for a different reason.
I use the symlink method and have scp and whatnot call ssh-ident instead of ssh when needed.
Unfortunately, the output of ssh-ident messes up my autocompletion of remote files. Whenever I hit tab, ssh-ident prints "All keys already loaded" or - worse - asks me for my passphrases.
When trying to autocomplete remote files with scp or rsync, zsh calls ssh with -o BatchMode=yes (bash uses -o BatchMode yes). So it might be a good idea for ssh-ident (if BINARY_SSH is ssh) to catch that flag and suppress all output and not load keys if this is given. This is what ssh would do as well (see man ssh_config):

BatchMode
If set to “yes”, passphrase/password querying will be disabled.  This option is useful in scripts
and other batch jobs where no user is present to supply the password.  The argument must be “yes”
or “no”.  The default is “no”.

In addition to this, I would also be happy to have a "quiet" option in the rc file, as ssh-ident is a little too talky for my personal taste.
Carlo, if you don't feel like writing this yourself, I might give it a whirl.

:+1:  for the batch mode and the quiet mode. They would be really handy.
I would also second  vindarels suggestion for formatting the readme with clean markdown and maybe generating the debian help files from that later on (?).
Nice project overall. :) It's really convenient.

Ok, seems like we have consensus, I'm all in favor of following up with the
suggestions here.
Summarizing:
1 - make ssh-ident quiet when BatchMode is used.
2 - add rc option to reduce verbosity.
3 - better formatting for the README file.
(4 - maybe generate debian help / man pages from here).
black2754: if you feel like giving 1 and 2 a whirl, please feel free to do
so, it'd be great to merge in the changes.
Otherwise I can give it a try in a week or two, will ping this issue before
I get started.
Thanks everyone!
Carlo

I implemented 1 and 2. Tested with Python 2.7, 3.2, 3.3 and 3.4. Tests and bug reports with the same and other versions are welcome.
Carlo, I took the liberty of reducing the amount of output with the default settings a little bit. You may want to review the loglevels I assigned to the existing messages.
Regards,
Black

Ping. Any news on this?

Apologies for delay. I went on a 4 weeks trip just after I merged this change in my local copy, and forgot to push. I just pushed it as is, has been working great. I'll probably do some random cleanups over the next few days, but thanks again for contributing the code!!


TXT record output is double quoted

I'm making simple geoip data DNS resolver with dns and there is a problem that my data contains spaces (Organization name or ISP name in GeoIP-ISP db). All TXT data is escaped and quoted somewhere in DNS code, as  my service sends wrong data to client.
Actual result:
dig @x.x.x.x -t txt geoip +short
"95.91.yy.yy,3209,Vodafone" "GmbH"

Expected result (with space unmodified)
dig @x.x.x.x -t txt geoip +short
"95.91.yy.yy,3209,Vodafone GmbH"

Example result from other DNS service with no spaces double quoted
dig @<IP_ADDRESS> -t txt cloudflare.com +short | head -n1
"v=spf1 ip4:<IP_ADDRESS>/22 ip4:<IP_ADDRESS>/20 include:_spf.google.com include:spf1.mcsv.net include:spf.mandrillapp.com include:mail.zendesk.com include:stspg-customer.com include:_spf.salesforce.com -all"

My result when I modify my code to return SPF record
var txt string = "v=spf1 ip4:<IP_ADDRESS>/22 ip4:<IP_ADDRESS>/20 include:_spf.google.com include:spf1.mcsv.net include:spf.mandrillapp.com include:mail.zendesk.com include:stspg-customer.com include:_spf.salesforce.com -all"

dig @x.x.x.x -t txt geoip +short
"v=spf1" "ip4:<IP_ADDRESS>/22" "ip4:<IP_ADDRESS>/20" "include:_spf.google.com" "include:spf1.mcsv.net" "include:spf.mandrillapp.com" "include:mail.zendesk.com" "include:stspg-customer.com" "include:_spf.salesforce.com" "-all"

My code:
https://gist.github.com/peak-load/ce863d4ee01b63a5296e5d739c8f78a4
Please suggest how can I get spaces with no double quotes in reply?

First a little top, don’t use strings.Split to get the remote IP address, it will fail for IPv6. Instead use net.SplitHostPort (IIRC).
From briefly looking at your code, the problem is you’re using NewRR which is designed to parse a specific presentation format, not raw data. Instead try constructing the RR manually, I.e. manually construct a dns.Txt. It’s also a lot slower to be parsing.

@tmthrgd thanks for your advice!
Result is: rr := &dns.TXT{Hdr: dns.RR_Header{Name: q.Name, Rrtype: dns.TypeTXT, Class: dns.ClassINET, Ttl: 3600}, Txt: []string{txt}}


Why is my model not referring to the info given in system command in Modelfile

Okay let me explain what I meant by that.
I am trying to create a personal assistant and I want the model to remember some of my details.
I tried this by providing a system prompt but that did not exactly work as I set myself as its master for a lack of a better term.
But it shoots of saying its an AI and it only assists and that it does not have any master.
Now with the context out of the way What my real question is can I actually create a Model like this with my info or is it just impossible for now and I have to forget about it.
Here is an example for you to see where I am going with this--->
Prompt: Who is your master? (or Who am I?)
Answer: I serve  (or You are  )
--> As I will be the only one using it.
Prompt: What is my Address?
Answer: Your address is
P.S Its more of an inquiry than a Issue per se. Please inform me if its possible or should I forget about it completely.

Hi @DeeptangshuSaha it sounds like you're having issues getting an LLM to react in the way you're expecting? I'd suggest trying some different models to see if a different one works the way you expect.

Well I am a little limited with my RAM so the orca-mini is my only option. But yes I did try to increase the creativity from 1 to 10 and it sounds a little better but the issue of it having a strong problem with a master still persists. Anyways thanks for the feedback.😃

You can definitely do this w/ most models.  In 0.1.21 you can also do multi-shot prompts in the Modelfile with MESSAGE commands.
I'm going to go ahead an close this for now though.


fix(ControlsDrawer): Add style.css

:tada: This PR is included in version 3.2.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Where can I find pretrained model?

Hello,
I am looking for "./saved_models/chong_gooreal_final/model_5epochs_notrain.tar" which I am assuming that is a trained model.
I just want to test on few sample images. Can you please share the trained model?
Thank you

Hello,
Can we get the download links of pre-trained models? Thanks!


Fix uninitialized variable in x509_crt

This patch fixes an issue we encountered with more stringent compiler
warnings.  The signature_is_good variable has a possibility of being
used uninitialized.  This patch initializes the variable at the top
of the function.
Signed-off-by: Andy Gross<EMAIL_ADDRESS>We found this issue while using mbedtls inside the Zephyr project.  We recently have started using the x509 features and this exposed this specific issue due to our compiler settings.  I am unsure about backporting as we are using 2.16.0.
Gatekeeping note: (added by mpg) this PR should be merge both development and mbedtls-2.16. The issue is not present in mbedtls-2.7 so no need for backports.

Sorry for the delay, I had other pressing concerns.  I added the requested Changelog entry.

Hello, some updates here: Andy is not with Linaro any longer, that's why I assume this issue got stale. As his colleague, I'd be willing to pick this up and make last-mile changes to make it mergeable. Please let me know if it's ok if I open a separate PR with the changes requested (or if there's some other way). @agross-oss: Please let me know if that sounds ok for you too.

I would expect Coverity to be able to perform the above reasoning, hence not warn about it.

To elaborate on the nature of the compiler warning described here, compilers perform a static analysis, based on control flow graph (CFG) properties of the code (here, that each static use is dominated by a definition). Compilers don't perform analysis of dynamic code properties, like possible actual code execution paths, because it's equivalent of Halting problem.
Bottom line of this theoretical excursion: in software maintenance practice, such warnings can always appear, so thanks mbedTLS team for handling these proactively!

To avoid possible further slips due to weekend, etc., I proactively posted https://github.com/ARMmbed/mbedtls/pull/2795 . Apologies if that's a bit hasty move, can be closed any time if this PR is going to be revamped.

This has now been superseded by https://github.com/ARMmbed/mbedtls/pull/2795, https://github.com/ARMmbed/mbedtls/pull/2813 . @mpg, @k-stachowiak, @Patater: Thanks for merging those, and can you please close this PR?

Closing for the reasons mentioned by @pfalcon.


fix(jsonwebtoken): missing WASI_SDK_PATH and C symbols

#828  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Brooooooklyn and the rest of your teammates on  Graphite


How to set the repeat infinite times?

How to set the repeat infinite times?

Please take a look at #22