javacc requires itself to build, bootstrap issue

It seems javacc is using its own solution to build itself. This is not really ideal as it creates a chicken and egg situation requiring use of a pre-built binary. Ideally there should be a clean solution to build from source. This maybe possible going back to an older version and chaining up from there. I have no problem with javacc using javacc for non-core aspects. But the initial build should not require javacc ,and then you can run what you just built to process any *.javacc files. Thank you for consideration of this request.

??? That's what we do. We use the previous version to built the current
version. I don't understand what the issue is.

It seems javacc is using its own solution to build itself. This is not
really ideal as it creates a chicken and egg situation requiring use
of a pre-built binary. Ideally there should be a clean solution to
build from source. This maybe possible going back to an older version
and chaining up from there. I have no problem with javacc using javacc
for non-core aspects. But the initial build should not require javacc
,and then you can run what you just built to process any *.javacc
files. Thank you for consideration of this request.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/javacc/javacc/issues/40, or mute the thread
https://github.com/notifications/unsubscribe-auth/ATQdrU6mVpfEr3-9o7r4DRAoJWf6AKUJks5tABF6gaJpZM4RA8_A.

There is no clean way to build from source without requiring a previously built binary. Which at that point, what is the point in building from source? If you have to use a pre-built binary. Might as well just run that binary.
It is not just javacc, many java projects seem to have circular dependencies, or worse a custom language that they use for the very project like javacc. Kotlin is a horrible new example of this. I really hope someday it ends. It is not a good trend or software development process.

Not sure what you are talking about here. This is bootstrapping 101. We
built a small core subset of javacc first and then bootstrapped using it
to build the next version. That's pretty well-understood development
paradigm.

There is no clean way to build from source without requiring a
previously built binary
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/dev-java/javacc/javacc-9999.ebuild#L51.
Which at that point, what is the point in building from source? If you
have to use a pre-built binary. Might as well just run that binary.
It is not just javacc, many java projects seem to have circular
dependencies, or worse a custom language that they use for the very
project like javacc. Kotlin is a horrible new example of this. I
really hope someday it ends. It is not a good trend or software
development process.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/javacc/javacc/issues/40#issuecomment-351491251,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATQdrfE__lFd1BljqybeKExZksC2iym2ks5tACD3gaJpZM4RA8_A.

 Software needs to stop requiring bootstrapping, IMHO. It is not a well understood paradigm, if anything it maybe a Java specific paradigm. I rarely see this in other languages. Short of a core/base system, in Unix, glibc, gcc, binutils, etc. The bootstrapping paradigm needs to end. It is not good. It makes it almost impossible to fully audit code....
I guess in Java who cares what is in the binary you are running right? No need to audit that for security, modifications, etc. What is the point of open source if you are required to use pre-built binaries to build open source code? Why build from source at all then?

A least in the area of compilers - it is pretty basic. I'm sure you need
gcc to build n old version of gcc. Check out the following thread:
https://stackoverflow.com/questions/9429491/how-are-gcc-g-bootstrapped
This has nothing to do with java. I do agree that it's not an easy
concept for many people but it's very effective way to do certain things.

Software needs to stop requiring bootstrapping, IMHO. It is not a well
understood paradigm, if anything it maybe a Java specific paradigm. I
rarely see this in other languages. Short of a core/base system, in
Unix, glibc, gcc, binutils, etc. The bootstrapping paradigm needs to
end. It is not good. It makes it almost impossible to fully audit code....
I guess in Java who cares what is in the binary you are running right?
No need to audit that for security, modifications, etc. What is the
point of open source if you are required to use pre-built binaries to
build open source code? Why build from source at all then?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/javacc/javacc/issues/40#issuecomment-351497386,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATQdrUQfcm5t1hQ3uf3VI1kJe7cRgEDGks5tACYzgaJpZM4RA8_A.

That is core stuff for obvious reasons. Javacc does not have to use itself to build itself. Those javacc files could be coded in regular java. Such that it could build entirely from source. Or at least the core, and then use what was built to process any javacc files.
IMHO it seems people are to eager to use their new shiny syntax, rather than Java code which it runs on. There is no need like in gcc. This is not like we are talking about the JDK itself. Which the java JDK can be 100% built from source going back to 1.5, using gcj, and gnu-classpath. So the gcc argument does not even apply to Java. If Java can be built 100% from source. Anything coded in Java should be able to do the same.
This is a choice of the project developers. It is not a hard requirement like with gcc. Take antlr 2.7.7 as an example. That can build 100% from source. Then antlr 3.x requires 2.7.7 to build. Then you can use 3.x to build 4.x. There is just another stringtemplate there that causes circular issues/bootstraping.
There are really a few Java projects out of hundreds that do this. I would like to see the trend and habit stop. Kotlin is a horrible new example coded almost entirely in Kotlin.... JRuby, Groovy, Jython and others are not as bad. Even Groovy can bootstrap itself without requiring a groovy binary. See me using a groovyc binary I just made, thus the relative path. That is what I am suggesting for javacc, and other projects as well. I am bringing this issue up with a number of projects.
I packaged hundreds of things, mostly Java but not all. This invent a language on top of another and require that to bootstrap is very much a Java specific thing. I cannot believe the amount of stuff that generates Java code. It is tremendous. I have yet to run into anything along those lines for other stuff. Why people want to code in Java not using Java is another paradigm I will likely never understand.

Of course javacc is a "compiler" that compiles javacc to Java code.  Your argument holds zero value for JavaCC.

That is core stuff for obvious reasons. Javacc does not have to use
itself to build itself. Those javacc files could be coded in regular
java. Such that it could build entirely from source. Or at least the
core, and then use what was built to process any javacc files.
IMHO it seems people are to eager to use their new shiny syntax,
rather than Java code which it runs on. There is no need like in gcc.
This is not like we are talking about the JDK itself. Which the java
JDK can be 100% built from source going back to 1.5, using gcj, and
gnu-classpath. So the gcc argument does not even apply to Java. If
Java can be built 100% from source. Anything coded in Java should be
able to do the same.
This is a choice of the project developers. It is not a hard
requirement like with gcc. Take antlr 2.7.7 as an example. That can
build 100% from source. Then antlr 3.x requires 2.7.7 to build. Then
you can use 3.x to build 4.x. There is just another stringtemplate
there that causes circular issues/bootstraping.
There are really a few Java projects out of hundreds that do this. I
would like to see the trend and habit stop. Kotlin is a horrible new
example coded almost entirely in Kotlin.... JRuby, Groovy, Jython and
others are not as bad. Even Groovy can bootstrap itself without
requiring a groovy binary. See me using a groovyc binary I just made
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/dev-java/groovy/groovy-9999.ebuild#L133,
thus the relative path. That is what I am suggesting for javacc, and
other projects as well. I am bringing this issue up with a number of
projects.
I packaged hundreds of things, mostly Java but not all. This invent a
language on top of another and require that to bootstrap is very much
a Java specific thing. I cannot believe the amount of stuff that
generates Java code. It is tremendous. I have yet to run into anything
along those lines for other stuff. Why people want to code in Java not
using Java is another paradigm I will likely never understand.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/javacc/javacc/issues/40#issuecomment-351500866,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATQdrWG95wojlfk1r4uBCS59m5V9bZ2uks5tACkrgaJpZM4RA8_A.

Again javacc does not have to use javacc code to build itself. JDK/javac is a compiler that can be built from source. So your saying it would be impossible to build Javacc using 100% pure java code? I do not believe that to be the case at all.
That seems to be more a deficiency of authors than the Java language. Which Java can build itself from source. I find it really hard to understand anything coded in Java cannot be built from source without requiring a binary to bootstrap. That seems like a bad design. Bad engineering.
It is a development choice, not a requirement. Nothing says Javacc has to use javacc to build itself. That is a choice of the developers. It was not even possible till the first version of javacc was built. Even GCC, something else has to build that first. Before you could use gcc to build future gcc. All things have an origin.
I am showing other things beyond jdk that can build from source, like antlr. There maybe some older version of javacc that is the same way. If I can figure out what ever version that is, I can chain up the versions to build the latest. I guess that is not something widely known. As javacc has likely bootstrapped since a very early version. A bad habit carried on for years.
Javacc generates Java code. There is nothing saying that same java code could not be written, and/or committed to the project as Java code. I am not sure I even understand the benefit of generating such code as part of a compile. It does not change. Thus it could be generated and committed as part of the projects code for any tag/release just the same. Multiple ways to go about it.
Again that is only a requirement because someone chose to code part of javacc using javacc compiler syntax/code. I find it hard to believe that had to be coded in javacc, and could not have been coded in pure Java. Its a choice, not a requirement. There is a difference.
Again take it how ever you will. But its not helping to make things any better.It just leads to things like Kotlin. It needs to end and stop. If you do not want to help make things better and just continue to propagate the old bad habits. That is each projects choice. It is a CHOICE, not a requirement. Given that fact I would hope people to be more open minded and find better solutions.
Again going back to why people even make compilers for other syntax and stuff on top of Java. That I will likely never understand nor like. I come across way to much of it.  I see no reason why that code has to be generated using the various tools. Only in rare cases like say apache poi converting office xml formats and what not into Java code. That makes sense. Most others thing do not.

@wltjr - I wish you good luck in your crusade against bootstrapping. We all need our pet peeves!

@matozoid Thanks :) But not really a crusade. Just going to bring it up and let upstreams decide. They have a choice to make software development better and friendlier to others or not. Seems most only care about their own needs not others. I am myself a selfish FOSS developer. But I would not ignore or not care about the needs of others using my stuff. I see that as a sign of being receptive to others. If I did not want others to use it, only for me needs, I do not need to make it open source or release to the world.
Once I do, I should consider the request and needs of others. The bootstrapping concept in general I would think most all to want to avoid vs embrace. I have no idea why this has become so acceptable in Java where it is really not in most everything else. it is also interesting some of this is related to colleges, like antlr/stringtemplate, and java_cup/jflex. Which both also have circular bootstrapping issues.
But if people really do not want to code in Java. Why they create a new language, syntax, compiler etc on top of Java does not make much sense either. Seems its to let people be lazy. Most any generated Java code could be hand coded just the same. What saves a developer time can cost all others. That is something I take into consideration. I rather cost myself more time once, and save all others time countless times. To much of software development has become the complete opposite
Anyway to each their own. I just try to use common sense, and plea to others to consider needs beyond their own. What makes your life better, may make it worse on others. Just hope more developers keep that in mind :)

To conclude, if javacc could consider one of the following approaches. That would be greatly appreciated!

Modify code so that javacc is not required to build javacc.
Generate files from javacc as part of release, like is done on maven sources. Not sure how feasible to do in repo with direct tarball download. If I use maven sources its not an issue. If the tarball can be made similar to that. Rather use direct sources from upstream/github than maven.
Move anything that needs javacc to build to non core, so the main core javacc compiler can be built, and then use that to generate any needed code. Like is done with groovy.

Or other options, those 3 were just the obvious ones. Any would help considerably. Thank you for your consideration and time :)

1 is a nonstarter. 2 is doable. Not sure about 3. I don't even understand the proposal.On Dec 13, 2017 1:03 PM, William L Thomson Jr<EMAIL_ADDRESS>wrote:To conclude, if javacc could consider one of the following approaches. That would be greatly appreciated!
Modify code so that javacc is not required to build javacc.Generate files from javacc as part of release, like is done on maven sources. Not sure how feasible to do in repo with direct tarball download. If I use maven sources its not an issue. If the tarball can be made similar to that. Rather use direct sources from upstream/github than maven.Move anything that needs javacc to build to non core, so the main core javacc compiler can be built, and then use that to generate any needed code. Like is done with groovy.
Or other options, those 3 were just the obvious ones. Any would help considerably. Thank you for your consideration and time :)
—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.

FYI 1 and 3 are part of the recommended solutions to the chicken and egg problem Javacc is already coded in Java mostly. That it requires javacc for itself seems to go against recommended solution to the problem created. Why it starts with saying use language X for Y. Which is what Groovy and others are doing. Even early antlr and stringtemplate. Just in updates got lost. In 1 there is no javacc code, in 3 java code builds javacc so that non core parts can be coded using javacc format/syntax to be "compiled" by javacc.
2 is just a idea based on how maven sources are generated. That is an option for tarballs, but would not be for anyone checking out live sources. Which 1 and 3 would be better solutions for live sources. Not to mention always bad idea to have binaries in source control. Though it is nice that is provided for bootstrapping purposes. For other packages, usually grab a jar of the same version as the tarball to use the jar for bootstrapping. But that can cause other problems when the jar was made with a different version of Java.
This requires a class file to be recompiled as the one in the jar has issues under Java 8. Hopefully most stuff is > 1.6, or will not even work in Java 9. Just some of the various issues that can arise from using pre-built binaries. Even for bootstrapping there can be issues.

Hello William
Could you explain in which way using a javacc previous version as a bootstrap in the building process prevents you from fully audit the javacc newly built version (security, modifications…)?
When you audit a source code version you do not audit the developer or the IDE or the generator that wrote the code, don’t you? You do not try to foresee what could be the next version of that source code and try to make audit prophesies on it?
Marc
De : William L Thomson Jr<EMAIL_ADDRESS>Envoyé : mercredi 13 décembre 2017 20:32
À : javacc/javacc<EMAIL_ADDRESS>Cc : Subscribed<EMAIL_ADDRESS>Objet : Re: [javacc/javacc] javacc requires itself to build, bootstrap issue (#40)
The bootstrapping concept needs to end and die is what I am saying. Software needs to stop requiring bootstrapping, IMHO. It is not a well understood paradigm, if anything it maybe a Java specific paradigm. I rarely see this in other languages. Short of a core/base system, in Unix, glibc, gcc, binutils, etc. The bootstrapping paradigm needs to end. It is not good. It makes it almost impossible to fully audit code....
I guess in Java who cares what is in the binary you are running right? No need to audit that for security, modifications, etc. What is the point of open source if you are required to use pre-built binaries to build open source code? Why build from source at all then?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/javacc/javacc/issues/40#issuecomment-351497386, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AWGYi5TJxa7n5kgjYr8llS6ifhrKkLXsks5tACYzgaJpZM4RA8_A.

@MarcMazas if there was a version of javacc I could build and then use that to bootstrap javacc I would be fine. There is no way to audit a binary jar. Which seems going back many versions there is no clean from source. I am working on this for other stuff, like jflex and javacup. I have found a old version of javacup, 10k that does not require jflex. Which I can use to then build jflex 1.4.3. Which then I use an older jflex 1.4.3 that has a pre-generated jflex file. Such that bootstrapping from that version is not required but I can use it for newer. Just realized they are also providing a generated cup file so I likely do not even need javacup at all for jflex 1.4.3. Generated by the very version of javacup I am using 10k. But I also need javacup 10k. to build javacup 11b. That shows 2 different project and how they have addressed the chicken and egg situation.
Now later versions of jflex >=1.5 no longer ships those pre-generated cups or jflex files. But at least a version can be used without any binaries. Same for javacup. Which 10k does not require any binaries to build. Which provides a clean path from source to build. Albeit through some older versions. They build and run fine under 9. Less an issue with jflex. Though seems more an issue with older jflex files or something. Like qdox 2 builds fine, but qdox 1.x has an error. The same one I get when using jflex 1.4.1 or 1.6.1 to build jflex. Which is ironic it has errors generating its own code :P

I'm pretty sure we never released that very first seed version as we did
it when we were working at Sun Micro and by the time we open sourced it,
it was already bootstrapped. And that's the only version that's
available in the open source.

@MarcMazas https://github.com/marcmazas if there was a version of
javacc I could build and then use that to bootstrap javacc I would be
fine. There is no way to audit a binary jar. Which seems going back
many versions there is no clean from source. I am working on this for
other stuff, like jflex and javacup
https://github.com/jflex-de/jflex/issues/271#issuecomment-351591437.
I have found a old version of javacup, 10k that does not require
jflex. Which I can use to then build jflex 1.4.3. Which then I use an
older jflex 1.4.3 that has a pre-generated jflex file
https://github.com/jflex-de/jflex/blob/release_1_4_3/jflex/src/JFlex/LexScan.java.
Such that bootstrapping from that version is not required but I can
use it for newer. Just realized they are also providing a generated
cup
https://github.com/jflex-de/jflex/blob/release_1_4_3/jflex/src/JFlex/LexParse.java
file so I likely do not even need javacup at all for jflex 1.4.3.
Generated by the very version of javacup I am using 10k. But I also
need javacup 10k. to build javacup 11b. That shows 2 different project
and how they have addressed the chicken and egg situation.
Now later versions of jflex >=1.5 no longer ships those pre-generated
cups or jflex files. But at least a version can be used without any
binaries. Same for javacup. Which 10k does not require any binaries to
build. Which provides a clean path from source to build. Albeit
through some older versions. They build and run fine under 9. Less an
issue with jflex. Though seems more an issue with older jflex files or
something. Like qdox 2 builds fine, but qdox 1.x has an error. The
same one I get when using jflex 1.4.1 or 1.6.1 to build jflex. Which
is ironic it has errors generating its own code :P
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/javacc/javacc/issues/40#issuecomment-351618710,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATQdrWZWDB2-z2w-N4gnP6sqgh-9ASJ1ks5tALyYgaJpZM4RA8_A.

I kind of like the idea of having it generated and committed to vc between tags/released. Like anytime the javacc source files change, then run javacc against them. That helps out considerable and eliminates the need for any past versions. Then you can do straight javac, and you have a current javacc  to do with as you desire :) That is done for maven, just not other tarballs, or committed to vc. I think ideal is committed to vc that way live building works as well, checkout from git, hack, etc.
Anyway no worries. There are others far worse. Least javacc just needs itself. Others like jflex and cups are not to bad. antlr and stringtemplate seem to be the worst. More so given their relation. Though someday still have to address kotlin, presently preventing progress on spring 5, though never finished deps for spring 4. I was working on maven from source and got stuck on some modello/plexus stuff that seems to only be used by maven to build maven... Less that maybe able to build maven from source without requiring maven for bootstrap as many have said and project itself says as means to build. Not sure about gradle, but seems mostly in groovy and I can bootstrap groovy. Lots of bootstrapping.... :)
Thanks for being receptive and sorry for all the noise.

Well, in that case things look simple: I do not see why using the javacc previous version instead of using that old “bootstrap.jar” version would not work. The test should not be difficult ☺.
I do this for JTB, which is a superset of JavaCC. The only annoying thing is that when I change the (JTB) grammar, I must check that the generated parser works well and one good way is to try to generated the “next” version and check it works, and if it does not invalidate the build.
De : William L Thomson Jr<EMAIL_ADDRESS>Envoyé : jeudi 14 décembre 2017 07:14
À : javacc/javacc<EMAIL_ADDRESS>Cc : MAZAS Marc<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Objet : Re: [javacc/javacc] javacc requires itself to build, bootstrap issue (#40)
@MarcMazashttps://github.com/marcmazas if there was a version of javacc I could build and then use that to bootstrap javacc I would be fine. There is no way to audit a binary jar. Which seems going back many versions there is no clean from source. I am working on this for other stuff, like jflex and javacuphttps://github.com/jflex-de/jflex/issues/271#issuecomment-351591437. I have found a old version of javacup, 10k that does not require jflex. Which I can use to then build jflex 1.4.3. Which then I use an older jflex 1.4.3 that has a pre-generated jflex filehttps://github.com/jflex-de/jflex/blob/release_1_4_3/jflex/src/JFlex/LexScan.java. Such that bootstrapping from that version is not required but I can use it for newer. Just realized they are also providing a generated cuphttps://github.com/jflex-de/jflex/blob/release_1_4_3/jflex/src/JFlex/LexParse.java file so I likely do not even need javacup at all for jflex 1.4.3. Generated by the very version of javacup I am using 10k. But I also need javacup 10k. to build javacup 11b. That shows 2 different project and how they have addressed the chicken and egg situation.
Now later versions of jflex >=1.5 no longer ships those pre-generated cups or jflex files. But at least a version can be used without any binaries. Same for javacup. Which 10k does not require any binaries to build. Which provides a clean path from source to build. Albeit through some older versions. They build and run fine under 9. Less an issue with jflex. Though seems more an issue with older jflex files or something. Like qdox 2 builds fine, but qdox 1.x has an error. The same one I get when using jflex 1.4.1 or 1.6.1 to build jflex. Which is ironic it has errors generating its own code :P
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/javacc/javacc/issues/40#issuecomment-351618710, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AWGYi1cPQ4NXfNyT6DS-Lig2bT7Pp2gZks5tALyYgaJpZM4RA8_A.

@MarcMazas that is what I am doing now but its not really ideal. It is some what nice that the needed bootstrap jar is within the sources. Normally dislike bundled binaries. Though when it is from the same upstream its a bit different. Still no way to see what is in that binary, just have to run it blindly and hope for the best :) I know that is an extreme example. I doubt its doing anything nefarious. Can't get much worse than most mobile devices these days... Its more the point that its not ideal in open source to just run others binaries. More so to generate a file that likely does not really change. Not like the result changes, maybe with a different version of javacc, or jdk. Though even then the result maybe the same.

By the way, there is a bunch of methods and classes generated by JavaCC that are not used by JavaC on parsing a grammar and generating a parser. Some look like old debug methods (dump* in SemanticChecker, LexGen. UnicodeConverter). The tool UCDetector helps finding them. For unused public classes it is little more difficult to point them (ExpansionTreeWalker, TreeWalkerOp, JavaFiles, LookaheadCalc, LookaheadWalk, MatchInfo, MetaParseException, OtherFilesGen, OutputFile, ParseEngine, ParseGen, Semanticize, in JavaCC 5.0).

That is good to know. I just generate what ever is needed to build. Likely could be optional parts not needed. Mostly needed as other projects have their own javacc source files. Not sure many compile against javacc, just use the compiler. Just use this to build other stuff :)


PV not provisioned with "xfs" filesystem.

Choose one: BUG REPORT or FEATURE REQUEST
BUG REPORT
What happened:
PV not provisioned with "xfs" filesystem.
What you expected to happen:
PV provisioned with an "xfs" filesystem
How to reproduce it (as minimally and precisely as possible):
Deploy latest openebs-operator (0.7.0) from "openebs-operator.yaml".
Deploy StorageClass with
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-mongodb
  annotations:
    cas.openebs.io/config: |
      - name: FSType
        value: "xfs"
provisioner: openebs.io/provisioner-iscsi

Provision volume with newly created storageclass.
Observe..
Anything else we need to know?:
From openebs-operator logs we can see that that CASVolume not received the "fsType" parameter from from the StorageClass
{"apiVersion":"v1alpha1","kind":"CASVolume","metadata":{"annotations":{"openebs.io/storageclass-version":"2141777"},"name":"test-test-xfs-216610947"},"spec":{"capacity":"1Gi","casType":"jiva","fsType":"","iqn":"iqn.2016-09.com.openebs.jiva:test-test-xfs-216610947","lun":0,"replicas":"3","targetIP":"\u003cno value\u003e","targetPort":"3260","targetPortal":"<IP_ADDRESS>:3260"},"status":{"Message":"","Phase":"","Reason":""}}

Environment:

kubectl get sc

NAME                        PROVISIONER                                                AGE
openebs-cstor-sparse        openebs.io/provisioner-iscsi                               3d
openebs-jiva-default        openebs.io/provisioner-iscsi                               3d
openebs-mongodb             openebs.io/provisioner-iscsi                               2d
openebs-snapshot-promoter   volumesnapshot.external-storage.k8s.io/snapshot-promoter   3d
openebs-standalone          openebs.io/provisioner-iscsi                               2d
openebs-standard            openebs.io/provisioner-iscsi                               2d

kubectl get pv

NAME                                 CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM                     STORAGECLASS      REASON    AGE
test-test-xfs-216610947          1Gi        RWO            Delete           Bound     test/test-xfs         openebs-mongodb             7s

kubectl get pvc
OS (e.g. from /etc/os-release):

NAME="Ubuntu"
VERSION="16.04.5 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.5 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

Kernel (e.g. uname -a):

Linux fsn-wrk1 4.4.0-131-generic #157-Ubuntu SMP Thu Jul 12 15:51:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Thank you @vitalka200 for finding this issue. There was indeed an issue with maya-apiserver fetching the value of FSType from storage class.
maya-apiserver expected the FSType was expected to be available as volume (controller) pod annotation, but it was being set only as annotation on volume (controller) deployment. The fix will be to update the annotation in the correct place and will be taken up for 0.7.1
You can apply the following file to patch the YAML in your setup to get the fix:
kubectl apply -f https://raw.githubusercontent.com/openebs/charts/master/store/openebs-0.7.0-hf-1907.yaml

After applying the above patch, the logs in the provisioner will still show FSType as empty, but you can verify the exact FS type used using the following methods:
(a) Check the PV spec
kubectl get pv <mongo-pv> -o yaml

(b) Check the mount output from the node where the volume is mounted.
kiran_mova@gke-kmova-helm-default-pool-1fd5d008-kstf:~$ mount | grep jiva
/dev/sdc on /var/lib/kubelet/plugins/kubernetes.io/iscsi/iface-default/<IP_ADDRESS>:3260-iqn.2016-09.com.openebs.jiva:default-mongo-persistent-storage-mongo-0-3274949689-lun-0 type xfs (rw,relatime,attr2,inode64,noquota)

Thank you @kmova. Working as expected. Is there any date when to expect the 0.7.1 release to be available?

Thank you for the quick confirmation  @vitalka200! 0.7.1 planned for end of this week.

Great. Thank you again.
Closing issue


Bring pthreads stub in line with pthreads v3.2.0

This doesn't include pthreads' new Socket class; my objective here is primarily to fix issues with static analysis tools which mis-report errors on code that works fine with v3.
pthreads v2 has been obsolete for 5 years, and cannot be used with anything newer than 5.6, so I don't consider dropping its classes problematic; however, if it is a problem, then phpstorm-stubs needs some way of versioning stubs because pthreads v2 and pthreads v3 have some changes as well as removals.

Hi @dktapps,
Please execute php generate-stub-map and commit the resulting PhpStormStubsMap.php

done, thanks!


Native iOS player for Safari in web app version

Have you read the Tutorials?
Yes
Have you read the FAQ and checked for duplicate open issues?
yes
What version of Shaka Player are you using?
3.2.0
Please ask your question
When I run shaka-player on my iOS device (iPhone, iPad)
It is overlapped with the iOS default native controls and I am not being able to use shaka UI in the browser safari or any.
Is there any way to hide or disable the iOS default UI control overlayed on the shaka-player?

Remove the controls attribute from the <video> element; or you can use video.controls = false in JS.

Thanks :tada: it worked


UserDialog Toast not showing in Android when enabled Proguard and change Linking to Sdk and User Assemblies (Xamarin Form))

Please check all of the platforms you are having the issue on (if platform is not listed, it is not supported)

[] iOS
[o] Android
[] UWP
[o] NET Standard 2.0

Version of OS(s) listed above with issue (if android - please include version of Xamarin.Android.Support.* you are using)
Android 7.1.1 to 9.0
Xamarin.Android.Support.v4 <IP_ADDRESS>
Xamarin.Android.Support.v7.AppCompat <IP_ADDRESS>
Version of ACR UserDialogs Library
7.0.4
Expected Behaviour
When I call the userDialogs.Toast("Successfully Update", TimeSpan.FromSeconds(4)) , the toast should show.
Actual Behavior
If applicable, please include entire exception - type, message, stacktrace
The toast does not show at all. The Toast only shows when I change the Linking in Android Properties -> Android Options -> Linking to None. If I change the Linking to Sdk and User Assemblies, toast not showing. Below is the assemblies that I included in 'Skip linking assemblies' -
Mono.Android;Plugin.CurrentActivity;Acr.UserDialogs;Behaviours.Forms;ExpandableView;Plugin.Permissions;Plugin.Forms.ButtonCircle;Rg.Plugins.Popup;SuaveControls.FloatingActionButton;Syncfusion.Licensing;Syncfusion.Xamarin.SfAutoComplete;VMS.ResidentMobileApp;Xam.Plugin.Media;Xam.Plugins.Settings;Xamarin.Essentials;Xamarin.FFImageLoading.Forms;Xamarin.FFImageLoading.Svg.Forms;Xamarin.FFImageLoading.Transformations;Xamarin.Forms;Xamarin.Forms.InputKit;Xamarin.Android.Support.v4;Xamarin.Android.Support.v7.AppCompat;Xamarin.Android.Support.v7.CardView;Xamarin.Android.Support.v7.MediaRouter;System.IdentityModel.Tokens.Jwt
I even add the ACR.UserDialogs in the skip linking assemblies but still toast is not showing. I know it has something to do with missing library during linking. But i just cannot find it which one.
Summary

With Proguard and Linking (None) - Toast is working
With Proguard and Linking (Sdk and User Assemblies) -  Toast not working
All the other functionality of the app is working accept this toast

Code of Conduct

No Library Update Requests - THIS ESPECIALLY MEANS ANDROID SUPPORT LIBRARIES
No Timeline Requests
Please read through the documentation and FAQs
Please be respectful of my time. I put a lot of effort into my libraries.  I try to support the issue requests within a day.  I'm not psychic, so please take the time to fill out the above form as complete as possible

Please supply an exception so I can see what’s being delinked

Bro It does not throw any error bro. I put try catch around it still it does not throw anything.

Please be respectful if you want help.  Calling me "bro" is not appropriate.
It likely isn't a linker issue if you aren't getting a MissingMethodException.  Do you see anything in the console output?  Do you have reproducible sample?

I'm sorry Mr Aritchie. I should not called you "bro".
I did'not see any error or weird output at the debug. I have created a sample that replicate the error. Try change the Android Properties
1 .-> Android Options -> Linking to None  (Working)
2. -> Android Options -> Linking to Sdk and User Assemblies (Not Working)
The file at link below
https://drive.google.com/open?id=16Ctbf6oZfcRKfeaA_P_0asUNSGz1yYQd

Hi, I'm getting the same issue when update from 7.0.1 to 7.0.4

In my case, when option "Use the concurrent garbage collector" is active (release mode) and  Linking Sdk Assemblies only, dialogs not show.
If I disabled garbage collector, dialogs show correctly

If you set your target to 9.0, then you need to upgrade your support libraries to <IP_ADDRESS>.  If you look at the buffet support for 7.0.4 of this library
Monoandroid81 uses 27.x support libs
Monoandroid90 uses <IP_ADDRESS>

@pablogupi I'm with same problem the dialogs not show, only appering the overlay. I've checkout your suggestions @aritchie and @pablogupi but the issue keeps. Thanks

@candidodmv Please don't post in closed topics.  If you target the proper android target of 9.0 with v<IP_ADDRESS> of the support libraries, it will work just fine


JSON nesting is limited to 32 levels

Summary
Our GraphQL query response JSON is now failing to parse due to exceeding 32 layers of nesting:
com.apollographql.apollo.api.internal.json.JsonDataException: Nesting too deep at [path]
Version
2.5.9
Description
Our API is quite complex and has now exceeded the recursion depth. The limit is hardcoded to 32 levels, however Moshi moved to 255 layers in May 2018.
Here's the line of code in apollo-android. Can the limit in Apollo-Android also be increased to 255?

Hi 👋 . That sounds very reasonable to me. Want to do a pull request?


Pull support-v4 from local support repository

If you have the SDK installed, you should have a local maven repository serving this file instead of including it as binary jar file. E.g. compile "com.android.support:support-v4:23.0.0" in your dependencies in app/build.gradle should work fine.

true. will fix tomorrow. thanks for noticing! ;)

tried to fix it via github.com on my mobile and failed horribly. probably missing a respository. will try again tomorrow. ;)

done


get property value + tests + doc

Codecov Report
Attention: Patch coverage is 86.66667% with 6 lines in your changes missing coverage. Please review.

Project coverage is 81.31%. Comparing base (818caa1) to head (6211ec5).

Files
Patch %
Lines

src/Client/RedisClient.php
80.00%
2 Missing :warning:

src/Om/Repository/HashModel/HashRepository.php
86.66%
2 Missing :warning:

src/Om/Repository/JsonModel/JsonRepository.php
87.50%
2 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##               main      #25      +/-   ##
============================================
+ Coverage     81.09%   81.31%   +0.21%
- Complexity      360      377      +17
============================================
  Files            38       38
  Lines           783      824      +41
============================================
+ Hits            635      670      +35
- Misses          148      154       +6

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


add sweeps for order and selection of prompts to eval against dev set, then run that for new data

addressed by commit 961b588f0316f3bbbcf931b6cb26d52b97a7853e


[HUDI-3087] Fix DedupeSparkJob typo

Tips

Thank you very much for contributing to Apache Hudi.
Please review https://hudi.apache.org/contribute/how-to-contribute before opening a pull request.

What is the purpose of the pull request
(For example: This pull request adds quick-start document.)
Brief change log
(for example:)

Modify AnnotationLocation checkstyle rule in checkstyle.xml

Verify this pull request
(Please pick either of the following options)
This pull request is a trivial rework / code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end.
Added HoodieClientWriteTest to verify the change.
Manually verified the change by running a job locally.

Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

@Aimiyoo hi, you would just use [MINOR] description  for the typo fix instead of creating a jira ticket.

@Aimiyoo hi, you would just use [MINOR] description  for the typo fix instead of creating a jira ticket.

OK，I see. I will pay attention to it next time.


Create Separate Usage Docs

Currently, all the documentation on how to interact with the API is in the README.
That information should be moved out to its own doc. Maybe a USAGE.md file or create a new page in the Wiki.
Maybe we explore using automatically generating API docs with packages like apidoc

I can take a stab at this!

This ticket has been addressed by the linked PR.


MoveToPokemonMap continues moving to a pokemon it has already caught

Expected Behavior
Should re-route after catching the pokemon it was moving toward
Actual Behavior
Continues to move toward pokemon spawn location
Steps to Reproduce
Config is as follows:
"type": "MoveToMapPokemon",
        "config": {
          "address": "http://localhost:5000",
          "max_distance": 500,
          "min_time": 60,
          "prioritize_vips": true,
          "snipe": false,
          "update_map": true,
          "mode": "priority",
          "catch": {
            "==========Legendaries==========": 0,
            "Aerodactyl": 1000,
            "Snorlax": 1000,
            "Articuno": 1000,
...

Other Information
OS: Windows 10
Git Commit: 6960f356a8d841cefbfd1018b23877b73a6a0d12
Python Version: Python 2.7.10

Doesn't seem to behave that way on my machine.

should probably be fixed with #2889 due to the catcherworker now catching every pokemon in a cell in a single tick.

I see similar behaviour. After catching the pokemon the bot keeps walking to the exact location of the pokemon. I assume this is because the pokemon is already within range ~0.06km from it's exact location. Not sure if this can be fixed.
2016-08-08 18:28:24,310 [MoveToMapPokemon] [INFO] [move_to_map_pokemon_move_towards] Moving towards Staryu, 0.09km, left (10 minutes, 53 seconds)
2016-08-08 18:28:32,698 [MoveToMapPokemon] [INFO] [move_to_map_pokemon_move_towards] Moving towards Staryu, 0.07km, left (10 minutes, 45 seconds)
2016-08-08 18:28:40,935 [PokemonCatchWorker] [INFO] [pokemon_appeared] A wild Staryu appeared! [CP 58] [Potential 0.36] [S/A/D 9/4/3]
2016-08-08 18:28:44,045 [PokemonCatchWorker] [INFO] [threw_pokeball] Used Pokeball, with chance 92.71 (1 left)
2016-08-08 18:28:44,674 [PokemonCatchWorker] [INFO] [pokemon_caught] Captured Staryu! [CP 58] [Potential 0.36] [9/4/3] [+210 exp]
2016-08-08 18:28:49,735 [MoveToMapPokemon] [INFO] [move_to_map_pokemon_move_towards] Moving towards Staryu, 0.06km, left (10 minutes, 28 seconds)
2016-08-08 18:28:59,340 [MoveToMapPokemon] [INFO] [move_to_map_pokemon_move_towards] Moving towards Staryu, 0.04km, left (10 minutes, 18 seconds)
2016-08-08 18:29:07,147 [MoveToMapPokemon] [INFO] [move_to_map_pokemon_move_towards] Moving towards Staryu, 0.03km, left (10 minutes, 10 seconds)
2016-08-08 18:29:14,750 [MoveToMapPokemon] [INFO] [move_to_map_pokemon_move_towards] Moving towards Staryu, 0.01km, left (10 minutes, 3 seconds)
2016-08-08 18:29:14,751 [MoveToMapPokemon] [INFO] [move_to_map_pokemon_encounter] Encountered Pokemon: Staryu

Other Information
OS: Linux
Git Commit: ff380cd
Python Version: Python 2.7.12

Same behaviour here.
Other Information
OS: Linux
Git Commit: 3c9806b
Python Version: Python Python 2.7.9

fixed


Strip units on passed in values to em/rem functions & mixins. Fixes #80

I've implemented strip-units to make these functions and mixins more robust. It also makes it less annoying when you have to change from raw px values to a function or mixin.
As v2 of Scally is no longer using rems on things like border and box-shadow, it makes it inconsistent that for these properties you have to type px values, but for em and rem functions, you have to use unitless.
At CM, I encountered this where I set variables for widths, and then @chris-pearce asked me to convert them to rems. At first I just wrapped them in a to-rem() function, but that errored, so had to change my values.
With this PR, a user can mix and match or use whatever they prefer.

Thanks for doing this but I need to look into this more. And off the top of my head; what about other mixins that except unitless values? Like:

https://github.com/chris-pearce/scally/blob/master/core/mixins/_font-size.scss
https://github.com/chris-pearce/scally/blob/master/core/mixins/_media-queries.scss

Plus GH saying this can't be merged, probably style.css?

Yeah, they should also be changed. I haven't used them yet, which is why they never crossed my mind :(
And yeah, style.CSS is a pain in the ass

What about setting values which are all unitless e.g.
$font-size: 16;

Well they were but now V2 has some px units e.g. https://github.com/chris-pearce/scally/blob/v2/objects/_o-arrow.scss#L22 which I agree is inconsistent so in these cases maybe I have to apply the unit within Scally to keep those px settings unitless e.g.
border: $o-arrow-size-base * 1px solid transparent;

https://github.com/chris-pearce/scally/blob/v2/objects/_o-arrow.scss#L41

Yeah, they should also be changed. I haven't used them yet, which is why they never crossed my mind :(

Yeah it would have to be applied across the board.

 I'd remove it now but I have to look into the package json setups as those can't break.

That's a crazy amount of overhead. And there's no way that anyone writing their custom CSS would adhere to that, so then you've instantly got 2 different styles of authoring units in a project

That's a crazy amount of overhead. And there's no way that anyone writing their custom CSS would adhere to that, so then you've instantly got 2 different styles of authoring units in a project

What are you referring to exactly? Please reference previous comments via ">>".

What are you referring to exactly? Please reference previous comments via ">>".
border: $o-arrow-size-base * 1px solid transparent;

(Quoting is hard work on a phone)

What are you referring to exactly? Please reference previous comments via ">>".
border: $o-arrow-size-base * 1px solid transparent;

(Quoting is hard work on a phone)

border: $o-arrow-size-base * 1px solid transparent;

I'm talking about handling this in the framework not expecting Scally users to do this and I'm doing this so Scally users can continue to apply unitless values to Scally settings e.g.
$o-arrow-size-base: 8;

To keep it consistent with the majority of other Scally settings which take rem units and up until V2 ALL Scally settings only accept unitless values.
Some examples:
$font-size: 16  !default;

$border-radius: 4 !default;

$breakpoints: (

  // Palm
  "palm":         640,

  // Lap
  "lap":          641,
  "lap-large":    901,

  // Desk
  "desk":         1200,
  "desk-large":   1366

) !default;

$text-input-and-select-border-thickness: 1 !default;

$hr-thickness: 1 !default;

I think it's confusing for the few Scally Version 2 settings that expect px now (border, box-shadow, etc) to have to apply the px unit. I want it all consistent as for sure after applying unitless values to the majority of Scally settings people will expect every Setting to work that way.

As I mentioned in my original issue, I personally prefer passing in px values to things, not unitless. I want to tell the mixin to use 20px, that's how my brain works, as I'm sure most web developers' brains do. 20px is my intended target (however that gets transformed on the other side), not just 20.
I'd be all for changing all values in Scally to have px on them.

I disagree, I think Scally should continue to be unitless. It is expected that any framework will have certain conventions you need to follow in order for the framework to function. While the goal of any framework developer should be to keep the learning curve low, I don't think it is unreasonable to expect a Scally user to have to learn a few Scally specific conventions. In this case it's learning to pass unitless values. In a responsive world passing 20px doesn't mean much anyway.

I personally prefer passing in px values to things, not unitless

I'm the opposite. And when Scally was created it was a very conscious decision to not make users of the fw apply units.

that's how my brain work

Not mine :)
I'll expand on this later as I need to crack on with V2.

Wow mine and @kllevin reply happened same time.

In a responsive world passing 20px doesn't mean much anyway.

I just don't get this. How is 20px any different to 20? The output will be identical.
Anyway, it was just a possible solution to mixed units issue. And, with stripping in place, you can quite happily continue passing in unitless if you like.

OK, I've stripped units on media-queries and font-size.
But I've also done something controversial: If you pass in a px line-height to the font-size() mixin, it will convert it to a unitless value.
So font-size(12[px], 18px) will output line-height: 1.5
IMO this is one of the strengths of using a pre-processor like Sass. I don't want to have to manually calculate that the line-height I need is 1.5, but I do know (as seen in the Photoshop comp) that it is 18px.

Long time listener, first time poster - just catching up on v2
In regards to the unitless and units discussion for passing arguments into functions, I think there’s a definite argument for maintainability to show the unit that people are passing in. Whether your way of thinking is pixels, ems, or rems - if another developer less well versed in the framework were to read your code, would it be obvious to them as to what was actually happening? What’s obvious to the creators of something isn’t always obvious to the users, being explicit can only be helpful for new adoption of the framework, requires less teaching, and causes less frustration.
I personally think in ems (thanks to years of multiplying by 16), others think in pixels - it’d be nice to know what figure went in. It does seem like Scally is using pixels anyway just without the unit.
In regards to there being a forced unit (rem) by convention, it seems contrary to what Scally is advertised as - an unopinionated framework. We have a toolbox in front of us, it seems weird to say we’re only going to use the hammer for everything, when a screwdriver might do the job better.
We have different unit types in CSS for a lot of reasons, some are scalable (ems), some are precise (px), there are plenty use cases for other unit types: VH - Full screen without CSS hacks or JS, VW - full screen, type , % - flexbox fallback, pixels - borders/ dropcaps / flexbox images.
In typography for example, there’s a strength in a typographic system being relative to its module over being relative to the document root, and it can be useful and more flexible to allow its font-sizing to cascade through the module. In this way ems are more flexible than rems. As Jason Santa Maria, who literally wrote the book On Web Typography (highly recommend reading!), says "Type is such a finicky beast that it needs to be judged optically first, not by the numbers.”
Convention and consistency are fine, but unit types shouldn’t be where the convention is enforced - units are different sets of tools applied to different situations.
Anyway, my two cents.

I can see the arguments for this making the framework more robust and flexible and I’m all for making the framework less frustrating. Up until now there hasn’t been any issues around not being able to attach “px” after the number you pass into mixins such as to-rem and to-em however after giving this more thought I do see how this can help the framework.
As this is a non breaking update to the framework I’m happy to add this, however I’m still not  comfortable everything has been covered. I’d like to discuss the changes more in general and so I will catch up with @stowball in person to go over it.
To echo what @kllevin said, you don't commit to using a CSS framework without spending some time learning its more complicated parts such as its mixins and functions i.e. its tools. I believe one of Scally’s strengths is everything is heavily commented e.g. and it has fully fleshed out README’s. This should also aid new adopters of the framework in understanding exactly what is going on.
The areas of the framework we’re specifically talking about effecting in relation to this PR are:
Functions

convert-px-to-em-rem.scs
^ a specific tool that takes a number and converts it to rem or em.

Mixins

convert-px-to-em-rem.scss
^ see above.

font-size
^ a specific tool that takes a number and converts it to rem and generates an optimal unitless line-height.

media-queries
^ a specific tool that takes a number and converts it to em.

Settings

Breakpoints
Spacing
Typography

Most frameworks—ones that I’m familiar with anyway—choose a core unit, some examples:

Inuit chooses px e.g.
https://github.com/inuitcss/settings.defaults/blob/master/_settings.defaults.scss#L19.

SUIT doesn’t really have one but in places enforces a unit like px e.g.
https://github.com/suitcss/components-grid/blob/master/lib/grid.css#L5
https://github.com/suitcss/components-grid/blob/master/lib/grid.css#L4

Bootstrap chooses px e.g.
https://github.com/twbs/bootstrap/blob/master/less/variables.less#L51
https://github.com/twbs/bootstrap/blob/master/less/variables.less#L90-L100, etc.

UI Kit chooses px e.g.
https://github.com/uikit/uikit/blob/master/src/less/core/base.less#L17

I guess you can strive to create a framework—that at its core—supports more than just one unit e.g.

Offering the core typography system for font size to work with px and em, not just rem?
https://github.com/chris-pearce/scally/blob/master/core/settings/_typography.scss#L11
https://github.com/chris-pearce/scally/blob/master/core/base/_root.scss#L30

Offering media queries to work with px, not just em?
https://github.com/chris-pearce/scally/blob/master/core/settings/_breakpoints.scss#L44-L57
https://github.com/chris-pearce/scally/blob/master/core/mixins/_media-queries.scss

Offering the spacing settings and utility to work with px and em not just rem?
https://github.com/chris-pearce/scally/blob/master/core/settings/_spacing.scss
https://github.com/chris-pearce/scally/blob/master/utilities/_u-spacing.scss

This is trying to do too much IMO.
Apart from the above Scally does not strictly enforce any other unit, for example, if in your component you want to use em for padding then you can do so, and is something we do at CM, e.g.
.c-pagination {
  @include to-em(padding, 24);
}

It’s worth saying though that perhaps Scally’s Button component needs to be revisited as the padding is using rem, see where it should perhaps be em? Maybe you can counter that with “but ems are too opinionated.” I guess you can’t please every scenario.
There will always be certain parts of a framework that have to be a little opinionated. In my opinion Scally does a great job minimising its opinionated bits and definitely does not force you to use rem for everything.
I had a little scout around and found some examples of other people's mixins/functions that do accept unitless and applying "px" and some examples that don't accept units as per Scally.

Bourbon

http://bourbon.io/docs/#px-to-em
http://bourbon.io/docs/#px-to-rem

SCUT

http://davidtheclark.github.io/scut/em.html
http://davidtheclark.github.io/scut/rem.html
http://davidtheclark.github.io/scut/rem-fallback.html

https://css-tricks.com/snippets/css/less-mixin-for-rem-font-sizing/
https://github.com/justinskolnick/unitize
https://github.com/zurb/foundation/blob/master/scss/foundation/_functions.scss#L106-L135
https://web-design-weekly.com/2013/05/12/handy-sass-mixins/ -> Font size

@chris-pearce As discussed, I've converted all settings that use px to be unitless, and am stripping the px inside the property. This means that by default, all Scally values are now unitless, but an author could use unitless or px throughout a Scally project whereever they like

@stowball nice work, looks good. I'll pull it down tomorrow and have a test, I don't trust myself now as I'm knackered. You'll need to rebase master in order to get the green merge button :+1:.

@kllevin have a gander.

I had the green button yesterday!  :P
All merged and updated now.

Also, as discussed, it's worth noting that 90% of the links to other frameworks that @chris-pearce provided strip units so accept both px and unitless. It'll be great to have Scally inline with the "general population" to make adoption easier.

Yes providing the ability to pass in px and a raw number makes sense. I just wanted to highlight that not everyone needs the px bit :).
And making sure it's understood that frameworks need to work with a core unit for some parts of the framework and that Scally holds true to being as unopinionated as it can possibly be esp, in the zero design department.
I'll get it merged tonight.

Closing this as its moved to PR #124.


Fastboot causes double decoding

when reading cookies in with fastboot they are being uri decoded twice causing an error if the cookie contains a %. This happens because fastboot uses the cookie package to parse the headers and add to the request object https://github.com/ember-fastboot/fastboot/blob/5a42df54ce3359a33589173d9c79a2236e619ba1/src/fastboot-request.js#L52 cookie calls decodeURIComponent by default when parsing https://www.npmjs.com/package/cookie#decode the value is then decoded again by ember-cookies https://github.com/simplabs/ember-cookies/blob/master/addon/services/cookies.js#L207.
a simple reproduction is
if (!this.fastboot.isFastBoot) {
  this.cookies.write('broken', '%')
}

this.cookies.read('broken')

I know there is a raw option i cannot use this since i'm using ember-cimple-auth. However i also don't think the current behavior is correct regardless since it would require it to be encoded on write and raw on read. I also don't think it would ever be the correct behavior to double decode something since this would change the format unexpectedly if someone intentionally double encoded something for some reason or if it similarly contained a restricted character.
I think the correct fix would be to never use decodeURIComponent when in fastboot
I am happy to submit a PR for this if you agree with the approach
for now my workaround is
_decodeValue(value, raw) {
  if (isNone(value) || raw) {
    return value;
  } else {
    try {
      return decodeURIComponent(value)
    } catch (error) {
      return value
    }
  }
}

This is obviously not great though since it overrides a private method and does not actually handle the double encoding problem but it solved my particular situation

Thanks for the report @arschmitz and sorry for the slow response. The solution you're suggesting (never calling decodeURIComponent when in FastBoot) seems correct. I think you'd just have to get that working correctly with the _fastBootCookiesCache where cookies are read from potentially and those reads would not go through cookie.parse and then.

@marcoow no problem on slow response its open source I know how it is. Ill do a PR for this when i have a few minutes


nbest rescoring with k2

check ci

Codecov Report

Merging #30 (3938316) into master (31de8f2) will increase coverage by 22.86%.
The diff coverage is 30.04%.

@@             Coverage Diff             @@
##           master      #30       +/-   ##
===========================================
+ Coverage   56.53%   79.40%   +22.86%
===========================================
  Files         741      413      -328
  Lines       64483    34717    -29766
===========================================
- Hits        36457    27566     -8891
+ Misses      28026     7151    -20875

Impacted Files
Coverage Δ

espnet2/asr/espnet_model.py
74.21% <6.45%> (-17.20%)
:arrow_down:

espnet2/fst/lm_rescore.py
13.04% <13.04%> (ø)

espnet2/lm/espnet_model.py
64.17% <20.00%> (-35.83%)
:arrow_down:

espnet2/bin/asr_inference_k2.py
67.69% <52.00%> (ø)

espnet/nets/pytorch_backend/nets_utils.py
85.15% <100.00%> (+0.35%)
:arrow_up:

espnet2/asr/decoder/transformer_decoder.py
96.63% <100.00%> (ø)

espnet2/train/abs_gan_espnet_model.py
0.00% <0.00%> (-100.00%)
:arrow_down:

espnet2/tasks/gan_tts.py
0.00% <0.00%> (-80.37%)
:arrow_down:

espnet2/hubert/hubert_loss.py
15.38% <0.00%> (-79.49%)
:arrow_down:

espnet2/gan_tts/espnet_model.py
0.00% <0.00%> (-77.50%)
:arrow_down:

... and 412 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 31de8f2...3938316. Read the comment docs.


Prefer using path module to guessing about cross-platform paths

I wouldn't do this: https://github.com/juuuuuuun/jun-ssg/blob/master/src/util/index.js#L22
Instead, use the path module to do all your work inspecting and creating paths.  I can do the right thing with the current platform and separators.

Same thing in https://github.com/juuuuuuun/jun-ssg/blob/master/src/util/index.js#L48


react-viro init ViroSample --verbose not work !!

I installed every thing that have mentioned if the official documentation but when I type react-viro init hello this error appear :
$ react-viro init hello
0.58.4
/usr/local/bin/react-viro: line 139: cd: hello: No such file or directory

+1

I installed every thing that have mentioned if the official documentation but when I type react-viro init hello this error appear :
$ react-viro init hello
0.58.4
/usr/local/bin/react-viro: line 139: cd: hello: No such file or directory

Following this instruction and after doing Copy Files from React Viro step, opened blacklist.js file from /project_root/node_modules/metro-config/src/defaults/ path and find var sharedBlacklist = [.
Change this line from
/node_modules[/\\]react[/\\]dist[/\\].*/,
to
/node_modules[\/\\]react[\/\\]dist[\/\\].*/,
Save and go back to root of peoject.
Now finish remained steps of mentioned instruction.


Add .pbp support for PSX

Using PBP files for PSX is the way to go. They are compressed versions of PSX meant to be used on the PSP system, but they work perfectly in the lr-pcsx-rearmed emulator, and they take up significantly less space than their CUE/BIN counterparts.

@BenWlson Great idea!  They also work great for Multi-Disc sets for games such as FF7.  The hard part however I would guess would be to do the hash as I could see most people when they build the PBP file end up with a different hash.  Maybe @sselph has an idea on how to add support.

The pbp files readily "available" online are inside a rar file. When extracted, you get eboot.pbp
I just rename this file to match the name of the original rar file.

I looked at this briefly but didn't get too far. I think the format is a container type format so might be possible to get at the underlying bin information to be able to hash it, similar to how I do zips. I may have to setup a windows machine and try creating one of these with known data to see if I can find it in the file afterward.

I'd close this.
It's a good idea but the container is not a standard which I think will work well for consistent hashes.

I've actually had luck with UXS matching the hashes with images on screenscraper.fr - maybe add it in at this point?

UXS use Hash at first and, if not found, try to match on Rom Filename. So if you have your PBP well named, it may found them ;)

@sselph would it be possible to scrape pbp files by name? Those files actually do have the complete binaries inside, although I don't think it would be easy to hash them. But being able to scrape pbp files by name (like mame I suppose), would allow us to scrape them easily.

Any new progress on this? I see PSX2PSP uses Game ID Numbers, is it possible to scrape based on that?


any chance you would make this unix friendly?

no access to a windows os atm

Was never a problem


Automate tests being run

It'd be good to have the tests automatically run including a coverage report as well as a badge in the readme.
Likely would have to setup Travis CI (or alternative) and use Coveralls.
Happy to submit a PR, but want to make sure it's wanted and that I don't step on anyone's toes.

I'm a bit confused -- we are already running tests using Travis CI. Did you maybe miss the existing badge on the README, or have you found a problem with the current configuration?
That said, I'd accept a PR for Coveralls - def not stepping on toes...

My apologies @dbarbalato I did miss the build badge. It'd be good to run on pull requests too (and report the status within Github) - I can take this task on
I'm happy to take on the Coveralls task too, if that's ok?

So again, unless I'm missing something, Travis CI currently runs on PRs too - check out https://travis-ci.org/captivationsoftware/react-sticky.
Coveralls would be a good addition, so by all means tackle that one if you want.
I'm going to close this out in anticipation of your PR - thanks!

Ahhhh... sorry! I completely missed it - I think because it doesn't seem to be reported as a status on the PR itself, but it looks like that's a config within Travis CI itself:

Anyway - sorry for being so confusing! I'll take a look at the Coveralls task too.

So I've never set up Coveralls but I synced up my account to use it -- here is the repo token they gave me, if you're going to proceed with the setup: NfW2NF4JMK2iRGH4rV8t4uhMFHxnLNBAd

@dbarbalato what @scottwarren means is that you can see the result of the tests inside the PR itself, like you see here for example 🙂


Resolve Markdown issues in README.md

Found via markdownlint *.md --disable MD033

:partying_face: :partying_face: :partying_face: :partying_face: :partying_face:


Support a new model

Do you have a plan to support JetMoE model (https://github.com/myshell-ai/JetMoE) that very effective to reduce computational cost in inference in litgpt?

Hi there,
thanks for suggesting! New models are always welcome. JetMoE is currently not on the priority list due to many other requests and features to be added, but if you want to contribute it, that'd be welcome!

I added a doc describing how to add a new model to LitGPT in case this comes in handy: https://github.com/Lightning-AI/litgpt/blob/main/tutorials/developer-docs/adding-models.md

I added a doc describing how to add a new model to LitGPT in case this comes in handy: https://github.com/Lightning-AI/litgpt/blob/main/tutorials/developer-docs/adding-models.md

Thanks so much for your information. It is really valuable for me.
Currently, I have a difficulty in updating the checkpoint conversion script (convert_hf_checkpoint.py) for the new model (jetmoe/jetmoe-8b). I think It needs another weight_map in the script. However, I don't find out some keys of the new model as follows.
weight_map = {
"model.embed_tokens.weight": "transformer.wte.weight",
"model.layers.{}.mlp.output_linear.weight":  ?, # ? mark means unknown key
"model.layers.{}.mlp.router.layer.weight":  ?,
"model.layers.{}.input_layernorm.weight":"transformer.h.{}.norm_1.weight",
"model.layers.{}.mlp.bias":  ?,
"model.layers.{}.mlp.input_linear.weight":  ?,
"model.layers.{}.post_attention_layernorm.weight":"transformer.h.{}.norm_2.weight",
"model.layers.{}.self_attention.experts.bias":  ? ,
"model.layers.{}.self_attention.experts.input_linear.weight":   ? ,
"model.layers.{}.self_attention.experts.output_linear.weight":  ? ,
"model.layers.{}.self_attention.experts.router.layer.weight":"transformer.h.{}.attn.experts.out_proj.weight",
"model.layers.{}.self_attention.kv_proj.weight":  ? ,
"model.norm.weight": "transformer.ln_f.weight",
"model.layers.{}.self_attention.q_proj.weight":"transformer.h.{}.attn.q_proj.weight",
"model.layers.{}.self_attention.k_proj.weight":"transformer.h.{}.attn.k_proj.weight",
"model.layers.{}.self_attention.v_proj.weight":"transformer.h.{}.attn.v_proj.weight",
}
Do you know any tools or documentations to find out those unknown keys?

That's a good question and usually the tricky part. It can be pretty hard to find the corresponding layer some times due to naming convention and sometimes because it may not be supported yet. I think in this case the LlamaMoE might be a good template to look at:
https://github.com/Lightning-AI/litgpt/blob/e2f8074b32ce08852f933636d1d81689990e1771/litgpt/scripts/convert_hf_checkpoint.py#L138

I haven't read the JetMoE paper, do they also have different attention experts? In this case, this would not be supported yet. The LlamaMoE is only for the MLP layers as in the Mistral.

Oh I see, the  Mixture of Attention heads (MoA) part will be a bit tricky then, that's currently not supported by LitGPT and would have to be coded. It might be a bit tricky for a contribution like this


Training doc

Please review this document and its associated images for potential inclusion in the Grobid documentation.  The idea would be to add more documentation around training in order to help people new to this to get up to speed quickly.
This is really just a first draft, based on a French Word document that was translated by me. There is obviously more work to do.  Thank you for your feedback.

Coverage remained the same at 34.836% when pulling beb58d2dd1ea22fde3159cbedec32a464f4ca991 on jfix:training_doc into d01bfa487f7d4d9dea6b2eb86718c17b3fc74d79 on kermitt2:master.

Coverage remained the same at 34.836% when pulling 40d671995c1bbf5e124a6753c5a62ea743e962b3 on jfix:training_doc into d01bfa487f7d4d9dea6b2eb86718c17b3fc74d79 on kermitt2:master.

Coverage remained the same at 34.836% when pulling 681708033ddd222f7a174500829ec66ce042f428 on jfix:training_doc into d01bfa487f7d4d9dea6b2eb86718c17b3fc74d79 on kermitt2:master.


Please write the documentation - how to install Codiad in Ubuntu/Apache2 at another port

The wiki is open for anyone. Feel free to add your extension how to configure another port


Update AlphaMaskReveal.html

The two variables , oldMidPt and oldPt, reference the same Point object.  It causes the curveTo() method to draw straight lines.

Based on this example, I revised the code to work with the ImageLoader in PreloadJS 0.6.0.
"EaselJS 0.8.0 & PreloadJS 0.6.0: Wiping out blur from a image with AlphaMaskFilter"
http://jsdo.it/FumioNonaka/feJF


Execution fails on Linux due to CRLF line endings

After installing via npm, running splashicon-generator on Linux fails with

/usr/bin/env: ‘node\r’: No such file or directory

And an inspection of node_modules/splashicon-generator/bin/splashicon-generator shows that line endings are CRLF. Changing it to LF, everything is good.

New version published to NPM


Fix mocking belongs_to associations in Rails 4.2+

Hi there - if you test rspec-activemodel-mocks against Rails' 4-2-stable branch, or against master, you'll get failures when mocking belongs_to assocations :
  4) mock_model(RealModel) as association that doesn't exist yet passes: associated_model == mock
     Failure/Error: @real.nonexistent_model = @mock_model
       Double "Other_1096" received unexpected message :_read_attribute with (:id)
     # /Users/jon/.rvm/gems/ruby-2.1.2/bundler/gems/rails-5383f22bb83a/activerecord/lib/active_record/associations/belongs_to_association.rb:80:in `replace_keys'
     # /Users/jon/.rvm/gems/ruby-2.1.2/bundler/gems/rails-5383f22bb83a/activerecord/lib/active_record/associations/belongs_to_association.rb:14:in `replace'
     # /Users/jon/.rvm/gems/ruby-2.1.2/bundler/gems/rails-5383f22bb83a/activerecord/lib/active_record/associations/singular_association.rb:17:in `writer'
     # /Users/jon/.rvm/gems/ruby-2.1.2/bundler/gems/rails-5383f22bb83a/activerecord/lib/active_record/associations/builder/association.rb:123:in `nonexistent_model='
     # ./spec/rspec/active_model/mocks/mock_model_spec.rb:130:in `block (3 levels) in <top (required)>'

Rails has recently added a _read_attribute method, which it uses internally instead of [].  How about the attached PR?

+1 Why it is not merged into master yet?

Rails 4.2.1 was just released, and rspec-activemodel-mocks is broken without this fix. Any chance of getting this merged soon?

Is there a workaround for this with Rails 4.2.1 and rspec?  I'm surprised nobody seems to be talking about it at all.

Yes, use @jdelStrother's branch

+1 for merge

Would love it if this got merged and released. Is there anything currently stopping it? It seems like the build breaks due to unrelated errors.

:+1: I doubt this will get merged until the specs are fixed.

The Travis builds that are failing are the same ones that fail on the stable/released version of this gem, and are largely failures on un-supported ruby versions (< 1.9.3).

Would be nice to drop them then.

:+1: hoping this gets merged.

I should mention that there are ways you can do without this gem and without mock/stub models generally. In my case, mock/stub models are useful because they are able to be assigned to actual model instances. Trying to assign a double or RSpec mock results in an ActiveRecord association error (since the assignment/association is expecting a particular model to be assigned).
It's easy enough to just stub the assignments in before blocks. Say you have a Post model under test (which belongs_to User), and in your test you need to assert that a User gets assigned to the Post. Since the Post model is an actual instance of Post, you cannot assign a User double, but you can if you stub assignment:
let(:user_double) do
  double("User double")
end

before(:each) do
  @post = Post.new
  @post.stub(:user=)
end

it "assigns the user" do
  @post.should_recieve(:user=).with(user_double)
  @post.method_under_test
end

Doing this allowed me to no longer rely on this gem. (Excuse my should_receive syntax as opposed to the newer "expect" syntax).

Superseded by #19


connector-post-status doc updated

https://phabricator.plugsurfing.com/T475

Did you work on master directly? The same change has to go into stable as well ...

usual github workflow:

fork master PlugSurfing/oioi-documentation to akhrol/oioi-documentation
change things on akhrol/oioi-documentation
commit, push to akhrol/oioi-documentation
create pull request from akhrol/oioi-documentation to PlugSurfing/oioi-documentation
etc

Yes. But doesn't apply here, as this is a change that has to go into stable as well.