Logit Bias is not having the desired effect when using ChatOpenAI - it doesn't seem like it's propagating to OpenAI call properly

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangChain documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I am sure that this is a bug in LangChain rather than my code.
[X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

Example Code
As a dummy example, let's try to stop a model using exclamation marks.
Using tiktoken, I can identify that the token for '!' is '0':

from langchain_openai import ChatOpenAI
logit_bias_dict = {'0': -100}

llm = ChatOpenAI(
    api_key=os.getenv("OPENAI_API_KEY"),
    model="gpt-4o",
    temperature=0,
    model_kwargs={"logit_bias":logit_bias_dict},
)

messages = [("human", "Write me a furious message as though you are screaming")]
response = llm.invoke(messages)
response.content

Error Message and Stack Trace (if applicable)
I get the following response, still with exclamation marks:
"ARE YOU KIDDING ME RIGHT NOW?!   HOW COULD YOU POSSIBLY THINK THIS WAS A GOOD IDEA?!  GET YOUR ACT TOGETHER IMMEDIATELY OR THERE WILL BE SERIOUS CONSEQUENCES!!"
Description
As you can see, it is not having the desired effect. I have also tried passing the logit bias dictionary to llm.invoke instead:
from langchain_openai import ChatOpenAI

logit_bias_dict = {'0': -100}

llm = ChatOpenAI(
    api_key=os.getenv("OPENAI_API_KEY"),
    model="gpt-4o",
    temperature=0,

)

messages = [("human", "Write me a furious message as though you are screaming")]
response = llm.invoke(messages, **{"logit_bias": logit_bias_dict})
response.content

which also has no effect. Conversely this works fine with OpenAI directly.
I have also tried using 0 instead of '0' (i.e. an integer instead of a string) - also no difference.
System Info
langchain                 0.2.1
langchain-community       0.2.1
langchain-core            0.2.3
langchain-openai          0.1.8
langchain-text-splitters  0.2.0
MacOS
Python 3.12.3

Upon closer inspection, I've realised this is also the case with OpenAI itself. Hence this is not an issue with langchain, so I will close the issue


Identity Authentication - missing Add-ObjectDetail function

hi,
getting the following error when trying to use with pspas module, after using use-PASSession $header
Add-ObjectDetail : The term 'Add-ObjectDetail' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the
spelling of the name, or if a path was included, verify that the path is correct and try again.
At [C:\Program](file:///C:/Program) Files\WindowsPowerShell\Modules\IdentityAuth\IdentityAuth.psm1:142 char:17
} | Add-ObjectDetail -TypeName psPAS.CyberArk.Vault.Sessi ...
~~~~~~~~~~~~~~~~
CategoryInfo         : ObjectNotFound: (Add-ObjectDetail:String) [], CommandNotFoundException
FullyQualifiedErrorId : CommandNotFoundException
Would it be possible to add this dependency in the identity authentication module please?

There are two thoughts here, we can or create our own function or import WFTools. We can also ask psPete module to make it public for us to use.


pass verification  Not Working

Sir it’s showing cannot pass verification stopping bot now

https://github.com/yuceltoluyag/Rise-of-Kingdoms-Bot#functions I wrote in this section that it is currently not working. I guess you didn't see it.
Will there be an update for the bot? I don't know for now. I work a lot (my main job is not to develop software) and I am reluctant. I might add a day. I didn't have much to do with the API, as I usually open the bot while I'm at the computer. The only reason for users to be banned is to verify the images with the api. If possible, use the bot while at the computer, stop the bot when the verification screen comes up and verify manually.

@ndhao164  thanks sir please fix it

@Usamarajputrok check it https://github.com/yuceltoluyag/Rise-of-Kingdoms-Bot/pull/7

https://github.com/yuceltoluyag/Rise-of-Kingdoms-Bot/releases/tag/0.0.1-Beta  Thanks for your support, I can't be at the computer much. I published your codes as a test if anyone wants to try https://github.com/yuceltoluyag/Rise-of-Kingdoms-Bot/releases/tag/0.0.1-Beta


nvm use issue -- 'C:\Program' is not recognized as

Expected Behavior
I expected to be able to change to the node version installed
Actual Behavior
The changing of version fails to execute the change.
Steps to reproduce the problem:
I'm using version 1.1.7 which is the current maintenance release.  I saw some issue posts that marked this as resolved before.  It appears to be related to the fact that "C:\Program Files" has a space in it.
I've been able to determine that in the Program Files\nvm directory there is a file settings.text that contains the following settings
root: C:\Program Files\nvm
path: C:\Program Files\nodejs

This appears to be the starting point of the error.   I tried manually changing the paths to the following.
root: "C:\Program Files\nvm"
path: "C:\Program Files\nodejs"

and several other combinations (i.e with %20 encoding)
I tried looking through the source code to find the point of the error but I couldn't quite get there.

I see that you already know about this issue in your common issues and are planning on fixing this in the 1.8 update.  -- Sorry --

My workaround for this was to install NVM into C:\tools\nvm and use C:\tools\nodejs as the symlink folder.

Until this is fixed, you can also work around it by changing the root and path in settings.txt to the short name version.
e.g.
C:\Program Files\ --> C:\Progra~1\
or
C:\Program Files (x86)\ --> C:\Progra~2\

Until this is fixed, you can also work around it by changing the root and path in settings.txt to the short name version.
e.g.
C:\Program Files\ --> C:\Progra~1\
or
C:\Program Files (x86)\ --> C:\Progra~2\

Spaces in paths are supported in https://github.com/coreybutler/nvm-windows/releases/tag/1.1.8

Until this is fixed, you can also work around it by changing the root and path in settings.txt to the short name version. e.g. C:\Program Files\ --> C:\Progra~1\ or C:\Program Files (x86)\ --> C:\Progra~2\

Suddenly i ran into this problem, even though it used to work. Your comment fixed the issue for me, thanks. <3


Converting from other library

Hi,
i have some code for arduino written in C with the library "arduinoFTT.h". I'm using an esp32 with micropython firmware so i need to translate that code to micropython.
The ftt related lines are:
FFT.Windowing(vReal, SAMPLES, FFT_WIN_TYP_HAMMING, FFT_FORWARD);   FFT.Compute(vReal, vImag, SAMPLES, FFT_FORWARD);   FFT.ComplexToMagnitude(vReal, vImag, SAMPLES);
where the values are these:
#define SAMPLES 512
double vReal[SAMPLES];
I can't understand how to convert to this library.
Can someone help me please?

This fft library uses STM assembler: it is intended for Pyboards and won't run on ESP32. I suggest you raise a general query on the forum.


Update earcut to 2.1.1

The built version linked in the earcut README was 2.0.8. I built the latest which is 2.1.1. The performance is about the same, but some of the triangulation errors in #4003 were fixed.

Can you submit an issue or PR for them to update the link?

Sure: https://github.com/mapbox/earcut/pull/64


Missing $lib/paraglide from skeleton project

When creating a project using bunx sv create new-project and selecting the options below, the app doesn't run with error ENOENT: No such file or directory
This seems to be because the project doesn't include the files necessary inside src/lib/paraglide which are referenced in the vite.config.ts file.
After commenting the paraglide plugin and the references in the project it can properly start.
┌  Welcome to the Svelte CLI! (v0.5.11)
│
◇  Which template would you like?
│  SvelteKit minimal
│
◇  Add type checking with Typescript?
│  Yes, using Typescript syntax
│
◆  Project created
│
◇  What would you like to add to your project? (use arrow keys / space bar)
│  prettier, eslint, vitest, playwright, tailwindcss, drizzle, lucia, paraglide
│
◇  tailwindcss: Which plugins would you like to add?
│  forms, container-queries, aspect-ratio
│
◇  drizzle: Which database would you like to use?
│  PostgreSQL
│
◇  drizzle: Which PostgreSQL client would you like to use?
│  Postgres.JS
│
◇  drizzle: Do you want to run the database locally with docker-compose?
│  Yes
│
◇  lucia: Do you want to include a demo? (includes a login/register page)
│  Yes
│
◇  paraglide: Which languages would you like to support? (e.g. en,de-ch)
│  es,en
│
◇  paraglide: Do you want to include a demo?
│  Yes
│
◇  Which package manager do you want to install dependencies with?
│  bun

Unfortunately, I'm unable to replicate the issue with the provided selections. Can you trim it down to only the minimally reproducible portions (i.e. only selecting paraglide rather than every add-on) and providing a link to a reproduction repo?

Same thing with minimal options selected, here's the link to the repo https://github.com/pe1uca/testSvCreate
┌  Welcome to the Svelte CLI! (v0.5.11)
│
◇  Which template would you like?
│  SvelteKit minimal
│
◇  Add type checking with Typescript?
│  Yes, using Typescript syntax
│
◆  Project created
│
◇  What would you like to add to your project? (use arrow keys / space bar)
│  paraglide
│
◇  Which languages would you like to support? (e.g. en,de-ch)
│  es,en
│
◇  Do you want to include a demo?
│  Yes
│
◇  Which package manager do you want to install dependencies with?
│  bun
│
◆  Successfully setup integrations
│
◇  Successfully installed dependencies

@pe1uca  I experienced the same issue, but it was eventually simply the fetch of inlang plugins from https://cdn.jsdelivr.net failing at compilation time.
When running pnpm dev I got several errors like the following:
ERROR  Couldn't import the plugin "https://cdn.jsdelivr.net/npm/<EMAIL_ADDRESS>
ModuleImportError: Couldn't import the plugin "https://cdn.jsdelivr.net/npm/<EMAIL_ADDRESS>
TypeError: fetch failed

I solved by disabling SSL verification for the process as a workaround.
HTH...

you can load the inlang plugins from node_modules via fs path instead. just install the packages for them as devDependency.

you can load the inlang plugins from node_modules via fs path instead. just install the packages for them as devDependency.

Can you give some more detailed instructions, please? I am pretty new and cannot get it to work.
bun add complains about blocked postinstalls and the provided steps don't work either.
Then I also do not know where I have to load the inlang plugins.
Maybe I should abandon bun for the moment.

Since this seems to be problematic for at least 3 users , we should check if we can find another way to do this.

you can load the inlang plugins from node_modules via fs path instead. just install the packages for them as devDependency.

Can you give some more detailed instructions, please? I am pretty new and cannot get it to work. bun add complains about blocked postinstalls and the provided steps to solve those don't work either. Then I also do not know where I have to load the inlang plugins. Maybe I should abandon bun for the moment.

Yeah I actually did it for job and you have to patch the package to remove the post install.
Curiously they basically just read the file and eval it instead of actually importing it so if you really want I guess you could include it just as a copy pasted file

you add this in paraglide settings.json instead of the jsdelivr urls
	"modules": [
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>	],

and you have to install each of the ones you need as devDependency. To prevent them from executing scripts you can use pnpms onlyBuiltDependencies or neverBuiltDependencies feature or just disable all post-install scripts (thats a safer environment but you might have some deps that depend on it working, put those in onlyBuiltDependencies then
https://pnpm.io/package_json#pnpmonlybuiltdependencies


Update for SILE v0.13.0

The current code seems to run just fine with SILE v0.13.0, but it is functioning only with the shim in place upstream for making old style classes work in the new system. Even the CI tests show us spewing warnings about the deprecations.
I can easily rewrite the FontProof class to use the new system, but once we do that we will break compatibility with older versions of SILE.
I suppose the best thing to do might be to hold out with things as they are in this package for a little bit to let v0.13.0 roll out to as many fontproof users as possible (it was released a week ago and most platforms got it right away but I only just got the Ubuntu builds updated in the PPA), then update the classes sometime before v0.14.0 hits.
Thoughts anyone?

Our toolchain is currently flagging these issues when using 0.13.1-1ppa1~ubuntu20.04 (from the Ubuntu PPA which we are using, IOW we are getting updates and are not pinning a particular version of SILE):
!     Use of SILE.require() is only supported in documents, packages, or class
init functions. It cannot be used before the class is instantiated.
Please just use the Lua require() function directly.
SILE.require("classes/plain") → require("classes/plain")
!     The document class inheritance system for SILE classes has been
refactored using a different object model. Your class (fontproof), has been
instantiated with a shim immitating the stdlib based model, but it is
not fully backwards compatible, will cause unexpected errors, and
will eventually be removed. Please update your code to use the new
Penlight based inheritance model.
std.object() was deprecated in SILE v0.13.0. Please use pl.class() instead.
! SILE.settings.() was deprecated in SILE v0.13.0. Please use SILE.settings:() instead.
! SILE.settings.() was deprecated in SILE v0.13.0. Please use SILE.settings:() instead.
This results in the builds of 11 font projects failing.
I think updating fontproof to follow the SILE classe changes is good to do. I don't know that we have many users who are stuck with an older version and are unable to upgrade to the newest SILE. It will be much easier for you to take care of that than for me, no doubt. What do you think @jvgaultney ?
We are currently still at v1.5.0 in the sile-packages catalog and I think we need to drop that line: https://github.com/sile-typesetter/sile-packages/blob/d9a7456c554dfb3da778f13e03d8f1469ad3c8bd/packages.lua#L10 so that updates can flow without having to change the catalog with every release/fontproof fix.

I think that having Caleb update fontproof to use the new classes would be good as SILE approached 0.13 and the shims are removed, and that we don't need to worry about backward compatibility. However we do need an immediate solution for our current build failures with 0.13.1.

Could you clarify what you mean by the shim in place upstream? This should be in the Ubuntu package, right? What am I missing?  Any clues about the cassowary error?

After looking at the repo and the docs some more I see what you mean with the shims.

I fixed the deprecation warnings (please check my work in sile-0.13.txt) and the cassowary error went away as well. I did not commit these changes, nor create a PR, because I still could not get FontProof to work.
I used the environment variable SILE_PATH so SILE could find FontProof. And SILE apparently read this variable, otherwise, how would have my changes made a difference? But after making the errors and warnings go away, SILE says
	/usr/share/sile/core/sile.lua:147: module 'fontproof' not found:
	no field package.preload['fontproof']could not load `ftl` file

I ran sudo install -m 644 classes/fontproof.lua /usr/share/sile/classes but this did not help.
I ran sudo install -m 644 classes/fontproof.lua /usr/share/sile and this had an affect. SILE said
Error detected:
	error loading module 'fontproof' from file '/usr/share/sile/fontproof.lua':
	/usr/share/sile/fontproof.lua:206: function arguments expected near '['

Line 206 does have some brackets []

If backwards compatibility isn't an issue just updating the class ASAP is probably the thing to do. I'll get on that right now...

I just applied the patch from @devosb, then fixed the bits that needed more TLC than a global search and replace ;-).
After that I rewrote the class to use the new Penlight object inheritance model. This means that it is now only SILE >= 0.13 compatible, but I suspect it will be easier to just get people to update SILE than it will be to try to do a patch release that supports the intermediate shims only to have to upgrade everything eventually anyway.
For my part I'll help keeping this working on current versions but supporting old versions because people don't want to upgrade anything else is probably more than I have time for. I already put weeks into making 0.13 break as few things as possible and adding shims so many projects would just keep working, but I know it didn't cover all cases and eventually had to move ahead or it was just never going to happen, which wasn't fair to projects wanting new features.

Sure, feel free to drop the release pinning there.
Also the big feature for 0.14 is going to be a sane package manager that works without root git access (like you seem to be doing) or SILE monkey patching (like the Docker container for this project does).

Do you guys want me to go ahead and get this in a major release bump? Or do you want me to cherry pick the SILE 0.12.x compatible fixes into a patch release first and save the SILE 0.13 exclusive change for a subsequent bump?

Huge thanks to you for doing all this improvement work. Yes please go ahead and make this a v1.6 release - no need to do a patch first.

@devosb The cassowary bug is completely independent. It is fixed in 2.3.2 but for some reason it looks like that build didn't make it into the PPA for all Ubuntu versions. I'll look into that:
lua-cassowary 	2.3.2-1ppa1~ubuntu22.10
lua-cassowary 	2.3.1-0ppa4~ubuntu18.04
lua-cassowary 	2.3.1-0ppa2~ubuntu22.04
lua-cassowary 	2.3.1-0ppa2~ubuntu21.10
lua-cassowary 	2.3.1-0ppa2~ubuntu20.04
lua-cassowary 	2.3.1-0ppa1~ubuntu21.04


Erroneous CSS color values due to a missing SASS partial/function

As the _mixins-utilities.scss file from the bootstrap-material-design project is missing,
SASS function contrast-color() is not available,
resulting in erroneous color declaration values like color: contrast-color(#3f51b5, #000000, #ffffff) in the compiled CSS (8 occasions/lines).

The fix is to add the _mixins-utilities.scss file to the project, @import '_mixins-utilities' in the beginning of the _mixins.scss file, and then recompile CSS.
I will open a PR with the fix.

@lembitk thank you for pointing out and for the PR. I've checked and it is right, we will add that in the next update release v1.2.0.
Best,
Alex


tracing: Add UUIDIntact config to tracer

Default to false and remove hyphens from generated uuids, as that could
break zipkin collectors.

Confirmed that this works on our staging service.


how can I work-around/fix "Unexpected token T"?

Can't decide if this is an issue or something I'm doing wrong.
This happens when I start node-inspector then open the url in the startup message. I can use NI successfully but sometimes it gets in these loops where I:

start NI
browse to URL provided
immediately get a message about socket closed
check terminal and see:

$ node-inspector
Node Inspector v0.12.1
Visit http://<IP_ADDRESS>:8080/?ws=<IP_ADDRESS>:8080&port=5858 to start debugging.
undefined:1
TypeError: undefined is not a function
^
SyntaxError: Unexpected token T
    at Object.parse (native)
    at Protocol.execute (_debugger.js:134:52)
    at Socket.emit (events.js:107:17)
    at readableAddChunk (_stream_readable.js:163:16)
    at Socket.Readable.push (_stream_readable.js:126:10)
    at TCP.onread (net.js:538:20)

Then I start the whole process again and it happens again. It's like there's some cached value that's causing NI to fail as soon as it tries to load up.
I can use NI successfully most of the time but these loops are frustrating.
$ versions
npm 2.14.2
node v4.0.0

(happened in 0.12.5 as well)

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/26710759-how-can-i-work-around-fix-unexpected-token-t?utm_campaign=plugin&utm_content=tracker%2F195817&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F195817&utm_medium=issues&utm_source=github).

Hello @jcollum
It will be useful to see your debug logs

OK I can post those next time it happens. I got it fixed today, I think by killing all my node processes.

The same happens to me too sometimes. Unfortunately I cannot provide precise steps to reproduce because it's kind of random and I'm not aware of any pattern in what I do. I did however manage to get the log (although I'm not sure if it's of any help).
node v0.12.7

I think this happens when the node process becomes disconnected somehow and is running off in the background even though you don't know it.  When this has happened to me I've looked in the various terminal windows I may have open to ensure that there are no running node processes.  Then I will list all of the running node processes on the system, inevitably there will be at least one which I then kill.  After that the debugger is up and running again without issue.

I hit this error today, here's the logging when I hit the error:
node-inspector:protocol:devtools frontend: {"id":49,"method":"Debugger.getScriptSource","params":{"scriptId":"87"}} +70ms
  node-inspector:protocol:v8-debug request: {"seq":35171,"type":"request","command":"scripts","arguments":{"includeSource":true,"types":4,"ids":[87],"maxStringLength":-1}} +1ms
  node-inspector:protocol:v8-debug response: {"seq":35,"request_seq":35171,"type":"response","command":"scripts","success":true,"body":[{"handle":12,"type":"script","name":"/Users/collumj/work/projects-aquaKod/monitoring/node_modules/aquaKod/dist/start.js","id":87,"lineOffset":0,"columnOffset":0,"lineCount":46,"source":"(function (exports, require, module, __filename, __dirname) { (function() {\n  var Manager, YAML, args, cl, configPath;\n\n  args = process.argv.slice(2);\n\n  console.log(\"process cwd: \" + (process.cwd()) + \"; args: \" + (JSON.stringify(args)) + \" \");\n\n  YAML = require('yamljs');\n\n  cl = new (require('./configLoader'))();\n\n  if (args.length === 1) {\n\n    /* assume the manager file is in this directory */\n    Manager = require('./manager');\n    configPath = args[0];\n  } else {\n\n    /* pull the manager in from the supplied path */\n    console.log(\"loading manager from  \" + args[1]);\n    configPath = args[1];\n    Manager = require(require(\"path\").join(process.cwd(), args[0].toLowerCase()));\n  }\n\n  cl.loadFromFile(configPath, (function(_this) {\n    return function(err, config) {\n      var m;\n      if (err != null) {\n        throw err;\n      }\n      m = new Manager(config);\n      return m.start(function() {\n        var msg;\n        msg = \"Manager start complete.\";\n        if (m.logger != null) {\n          return m.logger.warn(msg);\n        } else {\n          return console.log(msg);\n        }\n      });\n    };\n  })(this));\n\n}).call(this);\n\n});","sourceLength":1150,"scriptType":2,"compilationType":0,"context":{"ref":11},"text":"/Users/collumj/work/projects-aquaKod/monitoring/node_modules/aquaKod/dist/start.js (lines: 46)"}],"refs":[{"handle":11,"type":"context","text":"#<ContextMirror>"}],"running":false} +11ms
  node-inspector:protocol:devtools backend: {"id":49,"result":{"scriptSource":"(function (exports, require, module, __filename, __dirname) { (function() {\n  var Manager, YAML, args, cl, configPath;\n\n  args = process.argv.slice(2);\n\n  console.log(\"process cwd: \" + (process.cwd()) + \"; args: \" + (JSON.stringify(args)) + \" \");\n\n  YAML = require('yamljs');\n\n  cl = new (require('./configLoader'))();\n\n  if (args.length === 1) {\n\n    /* assume the manager file is in this directory */\n    Manager = require('./manager');\n    configPath = args[0];\n  } else {\n\n    /* pull the manager in from the supplied path */\n    console.log(\"loading manager from  \" + args[1]);\n    configPath = args[1];\n    Manager = require(require(\"path\").join(process.cwd(), args[0].toLowerCase()));\n  }\n\n  cl.loadFromFile(configPath, (function(_this) {\n    return function(err, config) {\n      var m;\n      if (err != null) {\n        throw err;\n      }\n      m = new Manager(config);\n      return m.start(function() {\n        var msg;\n        msg = \"Manager start complete.\";\n        if (m.logger != null) {\n          return m.logger.warn(msg);\n        } else {\n          return console.log(msg);\n        }\n      });\n    };\n  })(this));\n\n}).call(this);\n\n});"}} +4ms
  node-inspector:protocol:v8-debug request: {"seq":0,"type":"request","command":"disconnect"} +234ms
  node-inspector:protocol:v8-debug request: {"seq":0,"type":"request","command":"disconnect"} +2ms
  node-inspector:protocol:devtools frontend: {"id":1,"method":"Page.canScreencast"} +527ms
  node-inspector:protocol:devtools backend: {"id":1,"result":{"result":false}} +0ms
  node-inspector:protocol:devtools frontend: {"id":2,"method":"Page.canEmulate"} +1ms
  node-inspector:protocol:devtools backend: {"id":2,"result":{"result":false}} +0ms
  node-inspector:protocol:devtools frontend: {"id":3,"method":"Worker.canInspectWorkers"} +0ms
  node-inspector:protocol:devtools backend: {"id":3,"result":{"result":false}} +0ms
  node-inspector:protocol:devtools frontend: {"id":4,"method":"Console.setTracingBasedTimeline","params":{"enabled":true}} +0ms
  node-inspector:protocol:devtools backend: {"id":4} +0ms
  node-inspector:protocol:devtools frontend: {"id":5,"method":"Console.enable"} +1ms
  node-inspector:protocol:devtools backend: {"id":5} +0ms
  node-inspector:protocol:devtools frontend: {"id":6,"method":"Network.enable"} +0ms
  node-inspector:protocol:devtools backend: {"id":6} +0ms
  node-inspector:protocol:devtools frontend: {"id":7,"method":"Page.enable"} +0ms
  node-inspector:protocol:devtools backend: {"id":7} +0ms
  node-inspector:protocol:devtools frontend: {"id":8,"method":"Page.getResourceTree"} +1ms
  node-inspector:protocol:devtools frontend: {"id":9,"method":"Debugger.enable"} +0ms
  node-inspector:protocol:devtools frontend: {"id":10,"method":"Debugger.setPauseOnExceptions","params":{"state":"none"}} +0ms
  node-inspector:protocol:v8-debug request: {"seq":35172,"type":"request","command":"setexceptionbreak","arguments":{"type":"all","enabled":false,"maxStringLength":-1}} +0ms
  node-inspector:protocol:v8-debug request: {"seq":35173,"type":"request","command":"evaluate","arguments":{"expression":"JSON.stringify((function () {\n    return {\n      pid: process.pid,\n      cwd: process.cwd(),\n      filename: process.mainModule ? process.mainModule.filename : process.argv[1],\n      nodeVersion: process.version\n    };\n  })()).match(/.{1,80}/g).slice()","global":true,"maxStringLength":-1}} +1ms
  node-inspector:protocol:devtools frontend: {"id":11,"method":"Debugger.setAsyncCallStackDepth","params":{"maxDepth":0}} +0ms
  node-inspector:protocol:devtools backend: {"id":11} +0ms
  node-inspector:protocol:devtools frontend: {"id":12,"method":"Debugger.skipStackFrames","params":{"script":"","skipContentScripts":false}} +0ms
  node-inspector:protocol:devtools backend: {"id":12} +0ms
  node-inspector:protocol:devtools frontend: {"id":13,"method":"Runtime.enable"} +1ms
  node-inspector:protocol:devtools backend: {"id":13} +0ms
  node-inspector:protocol:v8-debug unknown: {} +0ms
  node-inspector:protocol:devtools frontend: {"id":14,"method":"DOM.enable"} +0ms
  node-inspector:protocol:devtools backend: {"id":14} +0ms
undefined:1
TypeError: this.extendedProcessDebugJSONRequest_ is not a function
^

SyntaxError: Unexpected token T
    at Object.parse (native)
    at Protocol.execute (_debugger.js:117:43)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:169:7)
    at readableAddChunk (_stream_readable.js:146:16)
    at Socket.Readable.push (_stream_readable.js:110:10)
    at TCP.onread (net.js:523:20)

Happening again today, same message:
undefined:1
TypeError: this.extendedProcessDebugJSONRequest_ is not a function
^

SyntaxError: Unexpected token T
    at Object.parse (native)
    at Protocol.execute (_debugger.js:117:43)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:169:7)
    at readableAddChunk (_stream_readable.js:146:16)
    at Socket.Readable.push (_stream_readable.js:110:10)
    at TCP.onread (net.js:523:20)

I can recreate this issue really easily by hitting the back button on the browser while debugging. The  Unexpected token T error happens instantly. Chrome 45.

I posted my debug logs a month ago guys. I've hit this error like 8 times in the last 15 minutes. It'd be nice to be able to fix this when NI gets into these failure loops.


Add additional query parameter options to CesiumViewer.

sourceType=czml/geojson/kml specifies the type of data to allow loading
URLs which don't have a file extension (such as a web service).
flyTo=false optionally disables the automatic flyTo after loading data.

@shunter, thanks for the pull request! Maintainers, we have a signed CLA from @shunter, so you can review this at any time.
:warning: I noticed that CHANGES.md has not been updated. If this change updates the public API in any way, fixes a bug, or makes any non-trivial update, please add a bullet point to CHANGES.md and comment on this pull request so we know it was updated. For more info, see the Pull Request Guidelines.

I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome.
:earth_africa: :earth_americas: :earth_asia:

example:
http://localhost:8080/Apps/CesiumViewer/index.html?source=https://stkonlinebeta.agi.com/api/vdf/items/b6e92d39844baecf5c8ef8cef06b64cb73daf930&sourceType=czml&flyTo=false

Looks good @shunter, thanks@


Hacktoberfest2019: add interview questions that you have solved

HACKTOBERFEST 2019
🎉🎉🎉🎉🎉

[UPDATED]
Goal:
The entire goal of this issue is to get contributions from the open source community to curate a list of interview questions which are solved in Python(3.7 preferred)
Note:

The interview questions can be of any level
please do not submit duplicate questions(go through the code base and see if the problem you are submitting exists)
All questions should have solutions written in python 3
Add tests to test your algorithm inside the root test folder
view the existing tests for implementation
PR will be rejected if it does not follow the above rules

Happy Hacking

yay:tada: I'll add one:octocat:

@adityaarakeri  I want to add question

@adityaarakeri Hey was lots questions I can add to this. How can I contribute?

follow these steps to contribute

make sure your code is in python3(>3.6)
add your code file in the appropriate folder, for example: if were solving a leetcode challenge put it in the leetcode folder
the solution can be a module or a class
add tests to test your algorithm in the root test folder.
when you create a PR, the CI will run your tests
once the tests are passed, we are good to merge it into master

@adityaarakeri Created a PR!

Hi, I am new to open source but I want to contribute a CodeWars problem and solution to the Code Wars folder. I followed a tutorial to use the Command Prompt but then at the end when I type 'git push origin branchname' I get an error saying:
'remote: Permission to adityaarakeri/Interview-solved.git denied to krobitaille93
fatal: unable to access 'https://github.com/adityaarakeri/Interview-solved.git/': The requested URL returned error: 403'

Hi, I am new to open source but I want to contribute a CodeWars problem and solution to the Code Wars folder. I followed a tutorial to use the Command Prompt but then at the end when I type 'git push origin branchname' I get an error saying:
'remote: Permission to adityaarakeri/Interview-solved.git denied to krobitaille93
fatal: unable to access 'https://github.com/adityaarakeri/Interview-solved.git/': The requested URL returned error: 403'

Try removing your GitHub password from your credential manager and then git push.

Hi, I am new to open source but I want to contribute a CodeWars problem and solution to the Code Wars folder. I followed a tutorial to use the Command Prompt but then at the end when I type 'git push origin branchname' I get an error saying:
'remote: Permission to adityaarakeri/Interview-solved.git denied to krobitaille93
fatal: unable to access 'https://github.com/adityaarakeri/Interview-solved.git/': The requested URL returned error: 403'

Try "forking" the repository and then "cloning" your version and then "pushing". I guess that'd remove the error.

Thanks for the response.
I ended up getting it to work properly by using a different computer. The first computer seemed to have some kind of issue with logging me into GitHub but I was not able to figure out the specific issue.

Can i contribute to this ? and this is the 1st time iam contributing to open source, so can you guide me with the steps?
Thanks in advance

closing for 2019.


Trailing comma: new feature from Kotlin 1.4

Kotlin 1.4 introduce the trailing comma feature. So we need to support it now not only for ENUMs as we did it before, but our code-style should force people to do this. For example:
fun foo(
    a: Int,
    b: String, // <--- this trailing comma is extremely useful for merging conflicts and swapping easily line without changing them
)

val colors = listOf(
    "red",
    "green",
    "blue", //trailing comma
)

same should be done for function calls/constructor arguments/e.t.c
Kotlin supports trailing commas in the following cases:
Enumerations
Value arguments
Class properties and parameters
Function value parameters
Parameters with optional type (including setters)
Indexing suffix
Lambda parameters
when entry
Collection literals (in annotations)
Type arguments
Type parameters
Destructuring declarations

It should be pretty easy to implement from the rules side, but the most important question here is: how should user specify language version? We should either support this setting in our plugin(s) or yml config, or once again consider moving from ktlint to detekt as backend, because detekt already supports such settings.

please have a look at #728 first

@kentr0w implement it like this: if there is a newline after the last element in parameter/argument list, then there should be a comma after it.
Obviousely, check that kotlin version is >= 1.4

@kentr0w please add it like this in the code style:
Since kotlin 1.4 you can use trailing comma in most list structures, including value argument lists, type parameter lists, parameters in indexing etc. Usage of trailing comma is recommended for long lists since it makes merging and resolving merge conflicts really seamless. If you use trailing comma, you should also put a line break after it.

Invalid code:
fun foo(
    a: Int,
    b: Int) {}

Valid code:
fun foo(
    a: Int,
    b: Int,
) {}


change E to int64 to fit bigger exponents we see in the wild

fork RSA from Go 1.5.3 :(

r? @oconnor663

Confirmed this fixes the problem with keybase id cr0bar

Oh dear. Is there a way to see a diff of what we changed, apart from the copies?

@oconnor663 I can see the changes here:
https://github.com/keybase/go-crypto/pull/8/files
Change to import, 1 if statement and the type change to int64
Both public key and public key v3 files changed.

Ignore my comment, realise what you mean now.

Our options are limited since the library we need to fix is in go core
On Saturday, February 6, 2016, oconnor663<EMAIL_ADDRESS>wrote:

Oh dear. Is there a way to see a diff of what we changed, apart from the
copies?
—
Reply to this email directly or view it on GitHub
https://github.com/keybase/go-crypto/pull/8#issuecomment-180707720.

the only change in the RPC library is from int to int64 and a few fixed
#-of bits computations
On Sat, Feb 6, 2016 at 7:09 AM, Maxwell Krohn<EMAIL_ADDRESS>wrote:

Our options are limited since the library we need to fix is in go core
On Saturday, February 6, 2016, oconnor663<EMAIL_ADDRESS>wrote:

Oh dear. Is there a way to see a diff of what we changed, apart from the
copies?
—
Reply to this email directly or view it on GitHub
https://github.com/keybase/go-crypto/pull/8#issuecomment-180707720.

My general strategy was just to change the type of E to int64 and then fix the compile errors are they came up. The actually use of the int is fine, since it's thrown up into a big.Int

No other comments, other than my general worry about changing crypto code. What's the class of keys that require this big E?

I've seen 3 offenders to far.  It's not changing the code that has me worried, as much as having to fork and missing security updates in the future.


Create ccsf.txt

@ego008 Please provide us with:

the university official website URL, if different from the domain you are submitting
an URL of a page on the official website where an IT-related long-term (>1 year) course is offered by the university
an URL of a page or another proof (.pdf or a screenshot are OK) showing that the university recognizes the domain which you are submitting as an official email domain for the students.

http://www.ccsf.edu/
http://www.ccsf.edu/dam/ccsf/documents/OfficeOfInstruction/Catalog/Programs/ComputerNetworkingandInformationTechnology/ComputerNetworkingandInformationTechnologyMajor.pdf
https://ssb-prod.ccsf.edu/web4stud.html


Add route for SSR

Add extra isBrowser config for webpack
Add extra content and diffItem window property for window.d.ts
Add react-router-dom for route usage
Add extra content and diffItem property for html.ts
Add shared folder for client/server routes usage
Modify index.tsx (server) for use react-router-dom with SSR
Add react-router support for client

Only a very roughly implements.
Now, we have several problems need fix:

Webpack will build both Route component and App component, so we have two same file generated.

Code highlight is disappeared. We need fix it.

And, we have several improvement:

Fix stylesheet for All component

Add style for Introduction component, which is the introduction of this course.


class jdk.internal.reflect.ConstructorAccessorImpl loaded by IntegroBridgeClassLoader cannot access jdk/internal/reflect superclass jdk.internal.reflect.MagicAccessorImpl

When using the 2.11.11 version in automatic mode we stumpled upon the error

{
	"title": "The provided class and method for setting environment variables is not valid.",
	"code": 500,
	"detail": "Linkage Error detected. This can be corrected by either setting the config value IBS.CLASSLOADER.INTEGRITY.MODE to 'automatic', or by enriching the IBS.CLASSLOADER.STATIC.INTEGRITY.PACKAGES property with the given path.",
	"bridgeServiceException": "com.adobe.campaign.tests.bridge.service.exceptions.IBSConfigurationException",
	"originalException": "java.lang.IllegalAccessError",
	"originalMessage": "class jdk.internal.reflect.ConstructorAccessorImpl loaded by com.adobe.campaign.tests.bridge.service.IntegroBridgeClassLoader @64989a8f cannot access jdk/internal/reflect superclass jdk.internal.reflect.MagicAccessorImpl"
}

Problem is by passed when passing the packages as arguments. It is also a bi-product of the, now disabled, auto-loadigng of dependencies.


Prepare shared UI design for all entity

Basic UI/UX https://tuiz.atlassian.net/wiki/spaces/MIC/pages/81494017/All+entity+Common+Design


LoadBalancingHttpClient is not properly handling max connections per host

When initializing the LoadBalancingHttpClient with poolEnabled, a CompositePoolLimitDeterminationStrategy is initialized at the class level (in LoadBalancingRxClientWithPoolOptions) that takes in perHostStrategy and globalStrategy as the parameters.
if (poolEnabled) {
            this.poolCleanerScheduler = poolCleanerScheduler;
            int maxTotalConnections = config.get(IClientConfigKey.Keys.MaxTotalConnections,
                    DefaultClientConfigImpl.DEFAULT_MAX_TOTAL_CONNECTIONS);
            int maxConnections = config.get(Keys.MaxConnectionsPerHost, DefaultClientConfigImpl.DEFAULT_MAX_CONNECTIONS_PER_HOST);
            MaxConnectionsBasedStrategy perHostStrategy = new DynamicPropertyBasedPoolStrategy(maxConnections,
                    config.getClientName() + "." + config.getNameSpace() + "." + CommonClientConfigKey.MaxConnectionsPerHost);
            globalStrategy = new DynamicPropertyBasedPoolStrategy(maxTotalConnections,
                    config.getClientName() + "." + config.getNameSpace() + "." + CommonClientConfigKey.MaxTotalConnections);
            poolStrategy = new CompositePoolLimitDeterminationStrategy(perHostStrategy, globalStrategy);
            idleConnectionEvictionMills = config.get(Keys.ConnIdleEvictTimeMilliSeconds, DefaultClientConfigImpl.DEFAULT_CONNECTIONIDLE_TIME_IN_MSECS);
        }

At the createRxClient we are using this poolStrategy which gets used in the ConnectionPoolImpl to check whether the client can create connection or not.  The problem here is that when there are more than one servers, they all share the same MaxConnectionsBasedStrategy which results in connection to other servers getting counted as their own. This results in the PoolExhastedException when the MaxConnectionsPerHost is set to smaller number than the total number of servers.
Because the maxConnectionsPerHost limitation is per host, the strategy should be initialized per server when creating the client and all servers should share the globalStrategy. Otherwise, the perHostStrategy is ineffective and acts as a globalStrategy instead.

PR you opened https://github.com/Netflix/ribbon/pull/295 (just to put the ref)

Is there any plans to close this issue in the nearest feature? As I can see problem is fixed and pull request opened.


ClusterClaim handles CD deletion better

Previously the ClusterClaim controller would only reconcile for a deleted ClusterDeployment if the CD was actually gone. Now it also notices if the CD has a deletionTimestamp or the remove-claimed-cluster-from-pool annotation.
Previously the ClusterDeleted condition was initialized to Unknown, and then eventually set to True, but was never False. Now we set it to False as soon as we ascertain the CD isn't deleted/deleting (per above new logic).

/assign @suhanime
/hold
for testing

/test e2e

/test e2e

NB: Latest force-push includes the same go.sum updates as https://github.com/openshift/hive/pull/1450. These should wash out in a rebase and/or on merge.

Previously the ClusterClaim controller would only reconcile for a deleted ClusterDeployment if the CD was actually gone. Now it also notices if the CD has a deletionTimestamp or the remove-claimed-cluster-from-pool annotation.

what is the benefit of this change?

what is the benefit of this change?

It should prevent you from claiming a CD that's already pending deletion.

what is the benefit of this change?

It should prevent you from claiming a CD that's already pending deletion.

the clusterpool controller shouldn't attach a cluster to claim that is not ready already?
https://github.com/openshift/hive/blob/616301492b6f2ff2e9eeadc156d4b780ce0f04de/pkg/controller/clusterpool/clusterpool_controller.go#L329-L331
ready => https://github.com/openshift/hive/blob/616301492b6f2ff2e9eeadc156d4b780ce0f04de/pkg/controller/clusterpool/clusterpool_controller.go#L261-L285

shouldn't attach a cluster to claim that is not ready

Correct. This handles timing issues where some other thread/agent deletes the CD after clusterpool_controller adds the claim info but before we get here.

You're right @abhinavdahiya, it should be impossible, in which case we're no worse off than we were before.

/test e2e

/test e2e
test env fixed

/test e2e

/lgtm

I'd like to land https://github.com/openshift/hive/pull/1460 and then revisit this.

#1460 removed the ClusterDeleted condition, so that part of this PR is obsolete.
The other part expands the invocation of reconcileForDeletedCluster, previously only triggered if IsNotFound(cd), to include when:

The CD's remove-claimed-cluster-from-pool annotation is set. This gets set to true by the clusterclaim_controller when the CD's claim is being deleted.
The CD's deletionTimestamp is set. This is done by the clusterpool_controller upon noticing the above label, as long as doing so won't exceed the pool's MaxConcurrent operations.

Since #1460, reconcileForDeletedCluster sets the claim's ClusterRunning condition to
Type: ClusterRunning
Status: False
Reason: ClusterDeleted
Message: Assigned cluster has been deleted

Arguably, we could have an interim phase like
Type: ClusterRunning
Status: False
Reason: ClusterDeleting
Message: Assigned cluster has been marked for deletion

which we set at the same time as updating the CD with remove-claimed-cluster-from-pool. This Reason would appear in the table output like:
[efried@efried ~]$ oc get clusterclaim claim-gllgp
NAME          POOL                     PENDING          CLUSTERNAMESPACE               CLUSTERRUNNING   AGE
claim-gllgp   fake-ocp-4-7-amd64-aws   ClusterClaimed   fake-ocp-4-7-amd64-aws-m2kkp   ClusterDeleting  4m23s

...which IMO would be better UX than it staying Running during the deletion phase.
@suhanime @dgoodwin thoughts?

I like it.

Done, with a rebase, and stacked on #1472 to make sure we're running the whole test :)

Tested live, works.


Adjust to new changes in timenode-core

Depends on https://github.com/ethereum-alarm-clock/timenode-core/pull/219.
Still untested.

Merging #103  > this one


Add test to verify that full_path in config.ini works properly #334

#334

Tracking test failure in dependent package hsoft/send2trash#36.


[feat-req] Add height preset

Hi,
I was checking the preset docs page of this package. I guess, adding a height preset will be great for people who want to create a collapse component.
This is useful in cases like: FAQ, QnA, Custom Collapse, etc.
Regards.

Hello :)
Thanks for the suggestion!
Could you provide examples of usage?
I would love to review a PR on that!
Let me know if anything is needed!

Hi,
Thanks for the response. Height preset will allow creating components like collapse easily.
Generally, when I want to create collapse I use v-show which doesn't trigger any animation. I am curious if vueuse/motion can provide something which we can combine with v-show or we can replace v-show with to create an animated collapse.
The reason I didn't do it myself is I don't know much about animation and more specifically I don't have much experience in vue animation via JS. Also, animating height is a bad idea to achieve 60fps smooth animation so experts might know how to achieve smooth animation for things like collapse.
Example of BSV: https://bootstrap-vue.org/docs/components/collapse

I am really sorry for the late answer.
I am looking forward to implement something like you mentioned (I understand the will to have a similar approach as v-show but animated).
That will be made possible by <Motion> component in v2 (#81 )

Hey! 👋🏻
So there is no way of having a working variant like this?
{
  initial: {
    opacity: 0,
    height: 0
  },
  enter: {
    opacity: 1,
    height: "auto"
  }
}

Or am I missing how to do that one well? 😄

AutoAnimate has this feature: https://auto-animate.formkit.com/#usage

@handhikadj I know that sine other do but I don't want to bring the big guns/have something external.
In the end, I found a CSS solution anyway so it's better. 😁

@kissu, could you post what your solution was so that others have an idea in the meantime?

@SelfhostedPro I pretty much used a blend between the 2 techniques described here. Really depends on your use-case but fixing it with CSS-only is probably the best way.
This one may also be quite useful depending on the browsers you need to support.

I achieved this with useElementSize from core.
<template>
    <div
        ref="containerRef"
        :style="{ height }"
        :aria-hidden="expanded ? undefined : 'true'"
        :inert="expanded ? undefined : ''"
        class="relative z-50 overflow-hidden bg-neutral-950 pt-2 transition-all duration-300 will-change-[height]"
    >
        ...
    </div>
</template>

<script setup lang="ts">
import { useElementSize } from "@vueuse/core"

const { expanded } = useNavigation()

const containerRef = ref<HTMLElement>()
const content = ref<string>()
const { height: targetHeight } = useElementSize(content, undefined, {
    box: "border-box",
})
const height = computed(() => (expanded.value ? `${targetHeight.value}px` : '0.5rem'))

onMounted(() => {
    content.value = containerRef.value?.children[0]
})
</script>


add spring boot configuration processor

Thi enable completion of jhipster properties in IDE
Fix jhipster/generator-jhipster/issues/10195
In future version of the lib, you will have this.

The current build in master is already broken for couchbase, so it's not related to this PR. That's why I'm merging this


Rust bindings: std feature used but not declared in Cargo.toml

The rust bindings currently have some conditional compilation based on the std feature, for example in https://github.com/supranational/blst/blob/v0.3.11/bindings/rust/src/lib.rs#L1093. This feature is however not specified in the Cargo.toml and thus cannot be enabled from the command-line when default features are disabled:
> cargo check --no-default-features -F serde -F blst/std
error: failed to select a version for `blst`.
    ... required by package `ethereum-consensus v0.1.1 (/home/jens/git/ethereum-consensus/ethereum-consensus)`
versions that meet the requirements `^0.3.6` (locked to 0.3.11) are: 0.3.11

the package `ethereum-consensus` depends on `blst`, with features: `std` but `blst` does not have these features.

failed to select a version for `blst` which could resolve this conflict

With a normal target this doesn't seem to be an issue, but compiling for SGX does not work for example:
> rustup target install x86_64-fortanix-unknown-sgx
> cargo check --no-default-features -F serde --target x86_64-fortanix-unknown-sgx
error[E0599]: no method named `aggregate_verify` found for struct `blst::min_pk::Signature` in the current scope
   --> ethereum-consensus/src/crypto.rs:105:25
    |
105 |     let res = signature.aggregate_verify(true, msgs, BLS_DST, &public_keys, true);
    |                         ^^^^^^^^^^^^^^^^ method not found in `Signature`

error[E0599]: no method named `fast_aggregate_verify` found for struct `blst::min_pk::Signature` in the current scope
   --> ethereum-consensus/src/crypto.rs:125:25
    |
125 |     let res = signature.fast_aggregate_verify(true, msg, BLS_DST, &public_keys);
    |                         ^^^^^^^^^^^^^^^^^^^^^ method not found in `Signature`

As far as I can tell, having the ability to manually enable the std feature (by listing it in Cargo.toml) would fix this issue.
Tested with https://github.com/ralexstokes/ethereum-consensus.git

In order to maintain backward compatibility implied by semver, std in 0.3.11 is an internal feature and a hard assumption is made that an "unknown" OS, such as x86_64-fortanix-unknown-sgx, doesn't provide an std environment. Well, apparently fortanix does. To determine the best course of action, do you know if it supports multiple threads?

It does support multiple threads, but there might be some differences in how they work or which functions are available in std. I've not done anything with multiple threads in x86_64-fortanix-unknown-sgx, so I can't say much about that.

Could you verify the following? In your etherium-consensus clone create .cargo/config.toml file with the following lines:
[patch.crates-io]
blst = { git = "https://github.com/dot-asm/blst", branch="unknown-std" }

and execute your test. And I mean some actual test, not just build sanity cargo check. (I ask, because I don't have a system with working fortanix edp.)

That solved the compiling problem, but when trying to run it in sgx I get the following error (probably related to the C code or how they're linked).
ERROR: Unsupported dynamic entry: .init functions
ERROR: while running "ftxsgx-elf2sgxs" "target/x86_64-fortanix-unknown-sgx/release/examples/bls" "--heap-size" "33554432" "--ssaframesize" "1" "--stack-size" "131072" "--threads" "1" "--debug" got exit status: 1

Code used: https://github.com/ralexstokes/ethereum-consensus/blob/main/ethereum-consensus/examples/bls.rs
Command used: cargo +nightly run --example bls --target x86_64-fortanix-unknown-sgx --no-default-features -F serde --release
I've also tried it with the following minimal binary, with the same error message, so it is not related to ethereum-consensus or other dependencies:
[package]
name = "blst-sgx-test"
version = "0.1.0"
edition = "2021"

[dependencies]
blst = { path = "blst/bindings/rust", version = "0.3" }

use blst::min_pk::SecretKey;

fn main() {
    let mut ikm = [0u8; 32];
    let sk = SecretKey::key_gen(ikm.as_slice(), &[]).unwrap();

    println!("Done");
}

Unsupported dynamic entry: .init functions

Ouch! cargo update and try again.

cargo update

Provided that you used the [patch.crates-io]. If you cloned unknown-std manually, refresh your copy:-)

Now it works, but only if the enclave is configured to have at least 2 threads (unless configured otherwise they only have a single thread).
[package]
name = "blst-sgx-test"
version = "0.1.0"
edition = "2021"

[package.metadata.fortanix-sgx]
threads=2

[dependencies]
blst = { version = "0.3.6" }
rand = "0.8.4"

When configured with only one thread I get the following error when trying to verify a signature:
Error while executing SGX enclave.
Enclave panicked: thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 11, kind: WouldBlock, message: "operation would block" }', /home/jens/.cargo/registry/src/github.com-1ecc6299db9ec823/threadpool-1.8.1/src/lib.rs:777:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

ERROR: while running "ftxsgx-runner" "target/x86_64-fortanix-unknown-sgx/debug/blst-sgx-test.sgxs" got exit status: 255

message: "operation would block"

Well, it originates in threadpool, so I'd be inclined to blame the threadpool:-) But did it work earlier? With 0.3.10 that is? Or did you have to engage the no-threads feature all along? If it worked, can you tell if it worked with a specific threadpool version? Is it possible that threadpool fails to note how many cores the enclave gets? After all, blst does take a note if there are multiple cores available and shouldn't take the blocking path...
For reference. It's generally beneficial to use parallelized interfaces, because even single-signature verification is parallelizeable.

so I'd be inclined to blame the threadpool:-)

Yes :)

But did it work earlier? With 0.3.10 that is?

I'm not quite sure what you mean: As far as I can tell the version in Cargo.toml doesn't matter when using [patch.crates-io] with the unknown-std branch. Previously it didn't even get to this point due to the .init problem. I've switched from using a local copy to the .cargo/config.toml override (wanted to try it out), maybe that's where the version change came from.

Or did you have to engage the no-threads feature all along?

I already forgot about that feature; It works if I set the amount of threads to >2 or if I use the no-threads feature, so I'd say it works as expected (either blst or threadpool doesn't see that only one thread is available, for some reason, but that's not a problem since multi-threadding can easily be disabled).

If it worked, can you tell if it worked with a specific threadpool version?

I don't think I ever tried a different version, unless you changed the threadpool version in the unknown-std branch.

Is it possible that threadpool fails to note how many cores the enclave gets?

Quite likely, I don't know. They probably check how many cores the cpu has (which is only one on the machine I'm testing on, making this situation weirder) and use that to estimate how many threads to start. Applications running normally in Linux can start as many threads as they want, but in SGX there are some extra things involved in creating new threads and they're thus limited to a fixed/max amount of threads.

because even single-signature verification is parallelizeable.

Interesting, I didn't know that.

But did it work earlier? With 0.3.10 that is?

I'm not quite sure what you mean:

I mean did it work 2 weeks ago, and if so, how exactly. It's assumed that the difference between 2 weeks ago and now is insignificant in respect to the problem at hand. Assumption can be wrong of course, but we have to explore the options:-)

I mean did it work 2 weeks ago

I see. I've not used blst before and was looking at the options for bls signatures and implementations of the ethereum consensus. Mainly to see which libraries works in SGX.
Therefore I don't know if it previously worked, this was the first/only version I tried.
I've just tested the following versions, all of which have the .init problem.

0.3.1
0.3.10
0.3.11

all of which have the .init problem.

But 0.3.11 is the first one that introduces the .init segment. Anyway, "I've not used blst before" effectively answers the question. It's more likely that it didn't work all along:-) I'll see what can be done and propose possible solutions here for you to test. Though probably not today... Meanwhile you can use no-threads feature for exploration purposes :-)

cargo update and try with single core and without no-threads. At least we'll know if fortanix threadpool correctly detects amount of assigned cores. (Next suggestion definitely not today:-) Cheers.

But 0.3.11 is the first one that introduces the .init segment.

Ah, that was my bad. I've specified the version as blst = { version = "0.3.9" } instead of blst = { version = "=0.3.9" }, thus it still took version 0.3.11. Here is a list of the behavior of the some recent versions (all tested with one thread, and without the no-threads feature):

0.3.1: operation would block
0.3.9: operation would block
0.3.10: operation would block
0.3.11: Unsupported dynamic entry: .init functions
unknown-std branch: operation would block

So the .init Problem really was just with version 0.3.11.
Using the no-threads feature also works in older versions (at least those that already had it).

cargo update and try with single core and without no-threads

Same behavior as last time:
Error while executing SGX enclave.
Enclave panicked: thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 11, kind: WouldBlock, message: "operation would block" }', /home/jens/.cargo/registry/src/github.com-1ecc6299db9ec823/threadpool-1.8.1/src/lib.rs:777:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

ERROR: while running "ftxsgx-runner" "target/x86_64-fortanix-unknown-sgx/debug/blst-sgx-test.sgxs" got exit status: 255

.cargo/config.toml
[patch.crates-io]
blst = { git = "https://github.com/dot-asm/blst", branch="unknown-std" }

[target.x86_64-fortanix-unknown-sgx]
runner='ftxsgx-runner-cargo'

Cargo.toml
[package]
name = "blst-sgx-test"
version = "0.1.0"
edition = "2021"

[package.metadata.fortanix-sgx]
threads=1

[dependencies]
blst = { version = "0.3.11" }
rand = "0.8.4"

cargo update and try with single core and without no-threads

Same behavior as last time:

Darn it! All right, time to look at threadpool... The panic line points at lib.rs:777 and this appears to be a function that spawn working threads. So that it ought to panic upon pool instantiation... Hmm... But could you try following first (to ensure that we don't hit the wall later on)? The error is likely to indicate that enclave threads are non-preemptive. Do you have a test that verifies a significant amount of signatures? Would it work with two threads allocated to enclave? blst's cargo test does it, so if it works, it would be sufficient. The idea is to ensure that there are no more "would block" panics...

Hmm... threadpool uses num_cpus and the latter unconditionally says there is just one cpu on "fringe" OSes, such as the one in question. This means that even if you assign 2 cores to enclave it will think there is only one cpu available. Incidentally this should still improve the performance of some operations, those that use even the "main" thread. I mean the "main" thread will be executing on one enclave thread and the threadpool would be executing on the second. This happens at least in the signature verification subroutine. As you might imagine, assigning more than 2 cores won't do anything. With this in mind, you can drop the previous request to perform some tests, it's more or less obvious that there won't be opportunities to block. But if you choose to perform those tests anyway, it would be interesting to confirm that [signature verification] performance actually improves with two threads. [Just in case, it won't double, because it's only partially parallelizeable.] The thing is that if performance doesn't improve for whatever reason, then there is no point in looking into it further, but to coerce no-threads. Well, which I'm leaning toward anyway... Alternative appears just too fragile to maintain:-(

I'm leaning toward [coercing no-threads]

This naturally doesn't preclude the possibility of revising it at a later point. Ideal coarse of action would be to have fortanix provide working threadpool, as opposed to grappling with the stock one. Collecting the performance data would serve as motivation factor;-)
On a more general note. As far as I can tell, when targeting sgx, rustc gets pretty aggressive with counter-measures to u-architecture attacks by default. This doesn't translate to the C part, not by default, let alone assembly. This effectively puts blst in a "privileged" position, it's bound to win all the benchmarks. Presumably with an impressive margin, because the said counter-measures are pretty expensive. Either way, this is not necessarily the trade-off you (or rather sgx users) would aim for:-) You can control C compilation by setting $CC to sufficiently recent clang and  $CFLAGS to match the rustc code generation settings. But this won't do anything to assembly. It's now possible to do #ifdef-ing in assembly, and it would be easy to replace ret-s with instruction sequences with lfence in the middle. Question is if it would be sufficient. One would have to make some assumptions, and strategically sprinkle lfense-s around, maybe even additional assembly subroutines... But it should be a separate issue... [If we choose to pursue this avenue.]

Here are some some benchmark results (all run with version 0.3.11). Keep in mind that (for simplicity) I'm always verifying 1000*num_threads_used signatures, so these benchmarks don't all have the same amount of computation to do):
It's also only a single measurement per configuration and measuring time in SGX is a bit more involved than on normal hosts (requires an ECall, and thus basically another context switch before we end up in normal user-land to make a syscall to get the time, if it is implemented that way), so take it with a big grain of salt.

Threads available
Threads used (including main thread)
features
Time taken
Time taken per 1000 Signatures

1
1
no-threads
1.2941s
1.2941s

1
1
-
-
operation would block

2
1
no-threads
1.3070s
1.3070s

2
1
-
1.3504
1.3504

2
2
no-threads
2.5912s
1.2956s

2
2
-
-
operation would block

3
1
no-threads
1.3030s
1.3030s

3
1
-
1.3503s
1.3503s

3
2
no-threads
2.5921s
1.2960s

3
2
-
2.6956s
1.3478s

3
3
no-threads
3.8843s
1.2947

3
3
-
-
Once instance has previously been poisoned

10
1
no-threads
1.3015s
1.3015s

1
1
-
1.3561s
1.3561s

10
9
no-threads
11.6725s
1.2969s

10
9
-
12.0236s
1.3359s

10
10
no-threads
13.0048s
1.3005s

10
10
-
-
operation would block

10
20
no-threads
-
operation would block

10
20
-
-
operation would block

As reference here are some measurements outside of SGX (running under normal linux):

Threads
Time taken
Time taken per 1000 Signatures

1
1.2811s
1.2811s

2
2.5647s
1.28235

10
12.8313s
1.2831s

It is apparently a hard limit on the number of threads that can exist at the same time, thus making anything with a non-pre-determined (compile time known) hard limit on the number of threads rather unreliable. Hence I'm tempted to always use no-threads in SGX, unless there actually is an upper bound to how many threads threadpool creates. It also probably depends quite a bit on the workload, as the communication between threads might be a bit more involved than it usually is.
The time (per 1k signatures) is most likely practically constant because we're CPU bound and I only have a single physical core available in the VM. Hence I cannot really measure how it works with 2 physical cores. It might also be that there is something else limiting how well it can be executed in parallel (we might be limited by ECalls: Calls between user-land and the SGX Enclave).
An interesting fact is that no-threads is (at least on this single-core CPU/configuration: Azure VM with a single core, Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80GHz) faster than if I specify no features. On normal linux they're quite neck-on-neck (probably only measurement errors), but in SGX it seems like no-threads is faster, regardless of how many threads I start in the application.
Interestingly, I've noticed that thread creation behaves differently depending on whether I use the no-threads feature. Without the feature it tends to start a bunch of threads in the beginning and actually executes them at the same time. Whereas I tend to get a single thread that finishes before the others start when using the no-threads  feature (it's almost always this way). Though that's of course up to so many different reasons that I wouldn't try to draw any conclusions out of that.
// With no-threads
Hello, world!
Done
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Done
Done
Done
Done

// Without no-threads
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Done
Done
Done
Done
Done

Here is a new error I encountered while trying different configurations. For some reason it only happened in this single configuration, and only in SGX, but it happens every single time.
Since you probably want to further investigate this error (unless it's already known): I've managed to reliably reproduce this bug in version 0.3.10 and the unknown-std branch, in both cases only without the no-threads feature and only when using 3/3 threads (including main thread) in the application. I don't know why, but it looks like we don't get to line where blst/threadpool tries to start a new thread and instead we get this error:
Hello, world!
Hello, world!
Attaching debugger
Error while executing SGX enclave.
Enclave panicked: thread 'main' panicked at 'Once instance has previously been poisoned', /home/jens/.cargo/registry/src/github.com-1ecc6299db9ec823/blst-0.3.10/src/lib.rs:35:14

ERROR: while running "ftxsgx-runner" "target/x86_64-fortanix-unknown-sgx/release/perf-measure.sgxs" "--" "3" got exit status: 255

For completeness, here is the code I was measuring with:
use rand::thread_rng;
use rand::RngCore;
use blst::min_pk::SecretKey;
use std::thread;
use std::time::Instant;
use std::env;

const BLS_DST: &[u8] = b"BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_";

fn main() {
    let args: Vec<String> = env::args().collect();
    let threads: usize = args[1].parse().unwrap();
    if threads == 0 {
        println!("Invalid arg");
        return
    }

    let start = Instant::now();

    let handles: Vec<_> = (1..threads).map(|_|
        thread::spawn(|| {
            do_stuff();
        })
    ).collect();
    do_stuff();
    let _x: () = handles.into_iter().map(|v| v.join().unwrap()).collect();

    let elapsed = start.elapsed();
    println!("Elapsed: {:.4?}", elapsed);
}
fn do_stuff() {
    println!("Hello, world!");

    let mut rng = thread_rng();
    let mut ikm = [0u8; 32];
    rng.try_fill_bytes(&mut ikm).unwrap();
    let sk = SecretKey::key_gen(ikm.as_slice(), &[]).unwrap();
    // let sk = SecretKey::random(&mut rng).unwrap();
    // let pk = sk.public_key();
    let pk = sk.sk_to_pk();
    // dbg!(&pk);

    let msg = b"Hello World";
    let sig = sk.sign(msg, BLS_DST, &[]);
    // dbg!(&sig);

    for _ in 0..1000 {
        let _res = sig.verify(true, msg, BLS_DST, &[], &pk, true);
        // dbg!(&res);
    }

    println!("Done");
}

Hmmm... Here is the difference I'm talking about. For your snippet, compare results on Linux for cargo run --release -- 1 and taskset 1 cargo run --release -- 1. You should see that the second command will show worse results. Because pinning to a single core effectively suppresses parallelization in sig.verify. And the expectation was that the same command with no-threads setup on SGX would be as slow as the latter, while a working with-threads setup on SGX would be as fast as the former. And we don't see any of the differences. Not even with Linux. What's up with that?
BTW, what is the expected application for SGX? Wouldn't performing secret key operations be the one? Almost exclusively? In other words we probably shouldn't be dying on the parallelization hill:-) But don't get me wrong, it's a meaningful exercise (at least for me) to figure things out, so thanks!

Since you probably want to further investigate this error (unless it's already known): I've managed to reliably reproduce this bug in version 0.3.10 and the unknown-std branch, in both cases only without the no-threads feature and only when using 3/3 threads (including main thread) in the application. I don't know why, but it looks like we don't get to line where blst/threadpool tries to start a new thread and instead we get this error:

I'm inclined to write it off as fortanix's problem. std::sync::Once is supposed to serialize invoking threads, and "poisoning" seems to mean that the first [and the only] invocation crashed. I wouldn't be surprised if it turns out to be a "would block" in disguise, which appears to be a "hard" limitation on fortanix edp. Well, it's possible to arrange a call for an application to make prior spawning own threads, as a way to ensure that there is no race to the Once instance in question. But since the idea is to coerce no-threads for now, it would be an unnecessary complication.

 Which makes sense to me.

And the expectation was that the same command with no-threads setup on SGX would be as slow as the latter, while a working with-threads setup on SGX would be as fast as the former. And we don't see any of the differences. Not even with Linux. What's up with that?

I guess that's because the Linux machine I was testing on only had a single physical machine (same one I used for testing SGX). We might see a difference if we had more than 1 physical core, but any kind of parallelization might suffer in SGX, as context switching likely has more overhead than on normal Linux (I've never tested that).

BTW, what is the expected application for SGX? Wouldn't performing secret key operations be the one? Almost exclusively? In other words we probably shouldn't be dying on the parallelization hill:-) But don't get me wrong, it's a meaningful exercise (at least for me) to figure things out, so thanks!

Primarily signature verification: Checking the Ethereum 2.0 Beacon chain signatures or at least those of the Sync Committee. But we might use it for signing, too, at some point. So secret key operation won't be the primary focus for now. Most likely we won't go with multiple threads anyways, unless absolutely necessary, so I fully agree with you. :)

I wouldn't be surprised if it turns out to be a "would block" in disguise

Could be, does the code run in std::sync::Once spawn threads if the no-threads feature is disabled? If yes, that would explain it.

But since the idea is to coerce no-threads for now, it would be an unnecessary complication.

:+1:

On the single-core system

Where does one find single-core systems nowadays?

901.5476ms vs. 1.0096s

Hmm... The improvement should be ~30%. ~10% sounds like you ended up on the same hyperthreaded core.

it only makes a significant difference if there are multiple physical cores available

Of course! I simply couldn't imagine that you would be exercising a single-core system:-)

what is the expected application for SGX?

Primarily signature verification

What's the point of executing it in SGX? I mean it's all public, while SGX is a tool for concealing things. Besides, as already mentioned, it comes with a hefty performance penalty. Even if there is no significant difference now, the correct course of future action is to align blst with the common SGX practices. I'm talking about -mlvi-hardening (default in x86_64-fortanix-unknown-sgx), and not only passing it to clang, but even modifying the assembly accordingly...

Where does one find single-core systems nowadays?

Cheapest Azure VM that supports SGX. Technically multi-core but the VM has only access to a single core.

What's the point of executing it in SGX? I mean it's all public, while SGX is a tool for concealing things.

We're having some secret data in SGX. Mainly a secret key for signing, although with a different signature scheme as of now. In addition to that the signing (and thus handling of the secret key) will likely be handled in a separate enclave and might in the future even calculated by multiple enclaves together (Multi-party-computation or threshhold-signatures), such that we don't rely on a single Enclave (perhaps not even just on SGX) to handle the secret key, as a protection against the worst-case scenario of SGX leaking data.
But this Enclave still requires knowledge about the public on-chain data, as it interacts with the chain while processing other transactions and/or data that is not available on-chain. Simplest use case: Someone deposits 1 ETH in a smart contract, the SGX enclave sees that information and based on that signs a message (in our case this is used as a proof that the enclave has seen this deposit and can be used to withdraw the deposit on-chain should the SGX enclave be stopped by the (untrusted/semi-trusted) host. To know what happened on-chain, without having to trust someone outside the Enclave we need to check if blocks from Ethereum are valid, thus we require Signature verification.

We proceed in #185. Thanks again!


Is there any method called when clicking the textinput or when its on focus?

I wanted to run some functions behind when it gets focus or a user clicks on the textinput.
Do you guys have any idea how do we do that ?

my bad i just figured out the onFoucs method


Add optional argument 'time_label' to 'timeline_slider'

Allows you to have a timeline which has a label other than "Time". Useful for when you want to animate your data over a non-temporal dimension, e.g. space.
Implemented as an optional argument to 'timeline_slider()', so usage looks like:
anim.controls(timeline_slider_args={'time_label': 'x position'})

Not sure if this should instead be implemented as an extra attribute on the timeline?

Thanks. This feature was already added in 0.3.0 as an argument named "text". It appears that you are working with an older version of animatplot (you'll need to rebase your github fork).

Yup. under Animation.timline_slider.
timeline_slider(text='Time', ax=None, valfmt='%1.2f', color=None, axis=None)

Parameters:
    text (str, optional) – The text to display for the slider. Defaults to ‘Time’
    ...

There was also a note in the changelog that mentioned it broke backwards compatibility with other positional arguments.


xcode 9 , swift 4 which version of realm supported?

we are actually upgrading to swift4 in xcode 9. when i tried to build the project it was reporting an error like "no viable overloaded '='". When i just goolge'd it. found like realm version 2.8.1 supports the xcode 9. but i am using 3.0.0-rc1 realm version.so wont it support xcode 9. Please correct me if i am deviating from the actual issue.
Realm framework version:  3.0.0-rc1
Realm Object Server version: ?
Xcode version: 9
iOS/OSX version: 10.12.6
Dependency manager + version: ?

@UmaRajesh Since version 2.8.1 or later (includes 3.0.0), Xcode 9 and Swift 4 are supported. Where does the error happen? Please tell me the details.

while i move my project to xcode 9 and build it . i am facing that issue. mainly in object.cpp file the error is reported for  m_notifier = std::make_shared<_impl::ObjectNotifier>(m_row, m_realm); line of code
NotificationToken Object::add_notification_block(CollectionChangeCallback callback) &
{
if (!m_notifier)
m_notifier = std::make_shared<_impl::ObjectNotifier>(m_row, m_realm);

even in result.cpp file. where ever the m_notifieris been used i am getting  the same error

Please share the full text of the error message, verbatim, including file name and line numbers. My suspicion is that you’re building an older version of Realm than you think you are, since this particular error was fixed a few months ago. Sharing the precise error message you’re seeing will help us to confirm that.

I have the same issue while trying to run realm 2.8.1 on  xcode 9 using swift 3.2
the error is:
No viable overloaded '='
/Users/diegowatanabe/adhawk-ios-new1/adhawk-new/Pods/Realm/include/impl/collection_notifier.hpp:231:13: Candidate function not viable: no known conversion from 'typename enable_if<!is_array::value, shared_ptr >::type' (aka 'std::__1::shared_ptrrealm::_impl::ResultsNotifier') to 'const realm::_impl::CollectionNotifier::Handlerealm::_impl::ResultsNotifier' for 1st argument

@diego-watanabe, Realm v2.10.1 is the first version of Realm that supports the Xcode 9 GM release. Older versions were only tested against prerelease versions of Xcode, not the Xcode 9 GM release.

Hi Realm Team,
INe We started tring from 3.0.0-rc1 of realm . Even that is not working. i
am just attaching the a screen shot of the error in object.cpp file. and as
i have listed, there are many places , this error is occuring.
Thanks,
M.UmaMageswari
On Thu, Oct 5, 2017 at 2:28 AM, Mark Rowe<EMAIL_ADDRESS>wrote:

@diego-watanabe https://github.com/diego-watanabe, Realm v2.10.1 is the
first version of Realm that supports the Xcode 9 GM release. Older versions
were only tested against prerelease versions of Xcode, not the Xcode 9 GM
release.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/realm/realm-cocoa/issues/5369#issuecomment-334263921,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AcFLUIdAUfRPvbpYhgZ7cPfwc0GJnngAks5so9xFgaJpZM4PtRwu
.

Your screenshot didn't come through, please re-attach it.

can you see the screen shot now?

@UmaRajesh, I'm not sure what version of Realm you're using, but it's definitely not v3.0.0-rc.1. The screenshot shows a copy of object.cpp identical to that found in realm/realm-object-store@9b159550e6310bdc6d1ccce355e8cb31a80aa2d1, which was currently around 8 months ago.  You can see at https://github.com/realm/realm-object-store/blob/f84d58a529ffb57e5b4d72c8d274c5215be0004a/src/object.cpp what the version used by v3.0.0-rc.1 looks like, and it's clearly different. For whatever reason, you're building a much older version of Realm than you intend to.
Have you run pod repo update recently to ensure that CocoaPods is aware of the most recent versions of all pods? If not, please do so.
I'd also suggest following the CocoaPods troubleshooting instructions mentioned in our documentation:
pod cache clean Realm
pod cache clean RealmSwift
pod deintegrate || rm -rf Pods
pod install --verbose
rm -rf ~/Library/Developer/Xcode/DerivedData

just followed all the  below steps. still when i build its showing the same error.
pod cache clean Realm
pod cache clean RealmSwift
pod deintegrate || rm -rf Pods
pod install --verbose
rm -rf ~/Library/Developer/Xcode/DerivedData
I am little new to this environment. could you please let me know how to know the version of realm i have, by any commands.
Note :  When i run "Pod update RealmSwift" I am getting the below error in terminal:
Pre-downloading: RealmSwift from https://github.com/realm/realm-cocoa.git, submodules true, branch master
[!] Failed to load 'RealmSwift' podspec:
[!] Invalid Realm.podspec file: Malformed version number string WARNING: The active Xcode command line tools, as returned by /Library/Developer/CommandLineTools, are not from Xcode.
The newest version of Xcode will be used instead.
3.0.0-rc.1.
from /var/folders/m7/t47xg0fd4lbdlw_rvqtcb9xm0000gn/T/d20171005-7747-czkz0c/Realm.podspec:12
-------------------------------------------
s.homepage                = "https://realm.io"

s.source                  = { :git => 'https://github.com/realm/realm-cocoa.git', :tag => "v#{s.version}", :submodules => true }

s.author                  = { 'Realm' =><EMAIL_ADDRESS>}
-------------------------------------------

Thanks for sharing that output. The immediate cause of the error it mentions is that you don't have a valid version of Xcode selected for your command-line tools. You can fix this by running sudo xcode-select -s /Applications/Xcode.app (fixing the path to Xcode.app as is appropriate for your system). After doing that, please try running pod update RealmSwift once more.

Thanks bdash!!  now landing up to another error. Command sequence is as follows
sudo xcode-select -s /Applications/Xcode9.app
pod update RealmSwift
Pre-downloading: RealmSwift from https://github.com/realm/realm-cocoa.git, submodules true, branch master
[!] Unable to satisfy the following requirements:

Realm (from https://github.com/realm/realm-cocoa.git`, branch master)required byPodfile`
Realm (= 3.0.0-rc.1) required by RealmSwift (3.0.0-rc.1)

That indicates your Podfile is specifying that Realm should use a branch from Git. It can't do that while also trying to install v3.0.0-rc.1. Easiest solution is to remove the Realm entry from your Podfile.

Now "pod update RealmSwift"  is working. but i could not convert RealmSwift from swift 3 to swift4.
I am getting the below error:
Showing Recent Issues
Command failed due to signal: Segmentation fault: 11
CompileSwift normal arm64
cd /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods
/Applications/Xcode9.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift -frontend -c /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/Aliases.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/Error.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/LinkingObjects.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/List.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/Migration.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/Object.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/ObjectiveCSupport.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/ObjectSchema.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/Optional.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/Property.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/Realm.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/RealmCollection.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/RealmConfiguration.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/Results.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/Schema.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/SortDescriptor.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/SwiftVersion.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/Sync.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/ThreadSafeReference.swift /Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/RealmSwift/RealmSwift/Util.swift -target arm64-apple-ios8.0 -Xllvm -aarch64-use-tbi -enable-objc-interop -sdk /Applications/Xcode9.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.0.sdk -I /Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Products/Debug-iphoneos/RealmSwift -F /Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Products/Debug-iphoneos/RealmSwift -F /Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Products/Debug-iphoneos/Realm -application-extension -enable-testing -g -import-underlying-module -module-cache-path /Users/uma/Library/Developer/Xcode/DerivedData/ModuleCache -swift-version 3 -enforce-exclusivity=checked -D DEBUG -serialize-debugging-options -Xcc -I/Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Intermediates.noindex/Pods.build/Debug-iphoneos/RealmSwift.build/swift-overrides.hmap -Xcc -iquote -Xcc /Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Intermediates.noindex/Pods.build/Debug-iphoneos/RealmSwift.build/RealmSwift-generated-files.hmap -Xcc -I/Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Intermediates.noindex/Pods.build/Debug-iphoneos/RealmSwift.build/RealmSwift-own-target-headers.hmap -Xcc -I/Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Intermediates.noindex/Pods.build/Debug-iphoneos/RealmSwift.build/RealmSwift-all-non-framework-target-headers.hmap -Xcc -ivfsoverlay -Xcc /Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Intermediates.noindex/Pods.build/all-product-headers.yaml -Xcc -iquote -Xcc /Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Intermediates.noindex/Pods.build/Debug-iphoneos/RealmSwift.build/RealmSwift-project-headers.hmap -Xcc -I/Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Products/Debug-iphoneos/RealmSwift/include -Xcc -I/Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/Headers/Private -Xcc -I/Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/Headers/Public -Xcc -I/Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/Headers/Public/FirebaseAnalytics -Xcc -I/Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/Headers/Public/FirebaseCore -Xcc -I/Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/Headers/Public/FirebaseInstanceID -Xcc -I/Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/Headers/Public/Google -Xcc -I/Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/Headers/Public/GoogleAnalytics -Xcc -I/Users/uma/Documents/GitHub/conpass-ios-retailer/Pods/Headers/Public/GoogleTagManager -Xcc -I/Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Intermediates.noindex/Pods.build/Debug-iphoneos/RealmSwift.build/DerivedSources/arm64 -Xcc -I/Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Intermediates.noindex/Pods.build/Debug-iphoneos/RealmSwift.build/DerivedSources -Xcc -DPOD_CONFIGURATION_DEBUG=1 -Xcc -DDEBUG=1 -Xcc -DCOCOAPODS=1 -Xcc -ivfsoverlay -Xcc /Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Intermediates.noindex/Pods.build/Debug-iphoneos/RealmSwift.build/unextended-module-overlay.yaml -Xcc -working-directory/Users/uma/Documents/GitHub/conpass-ios-retailer/Pods -emit-module-doc-path /Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Intermediates.noindex/Pods.build/Debug-iphoneos/RealmSwift.build/Objects-normal/arm64/RealmSwift.swiftdoc -serialize-diagnostics-path RealmSwift.dia -Onone -module-name RealmSwift -emit-module-path /Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Intermediates.noindex/Pods.build/Debug-iphoneos/RealmSwift.build/Objects-normal/arm64/RealmSwift.swiftmodule -emit-objc-header-path /Users/uma/Library/Developer/Xcode/DerivedData/conpass-ios-retailer-gfjbrzzgnbawtxaopwtjozvfbydi/Build/Intermediates.noindex/SwiftMigration/conpass-ios-retailer/Intermediates.noindex/Pods.build/Debug-iphoneos/RealmSwift.build/Objects-normal/arm64/RealmSwift-Swift.h -emit-dependencies-path RealmSwift.d -emit-remap-file-path RealmSwift.remap -o RealmSwift.o -embed-bitcode-marker
0  swift                    0x0000000110e56dba PrintStackTraceSignalHandler(void*) + 42
1  swift                    0x0000000110e561f6 SignalHandler(int) + 662
2  libsystem_platform.dylib 0x00007fffb7724b3a _sigtramp + 26
3  libsystem_platform.dylib 0x00007fab4b8c01c8 _sigtramp +<PHONE_NUMBER>
4  swift                    0x000000010e48fff0 swift::migrator::updateCodeAndEmitRemap(swift::CompilerInstance*, swift::CompilerInvocation const&) + 960
5  swift                    0x000000010d7c6775 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 1925
6  swift                    0x000000010d7c4784 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 7716
7  swift                    0x000000010d7796a8 main + 12248
8  libdyld.dylib            0x00007fffb7515235 start + 1
9  libdyld.dylib            0x0000000000000076 start +<PHONE_NUMBER>
Stack dump:
0.	 Realm Swift is already written in Swift 4.

yeah thats my bad. i should not do that. thanks for the information and support

you is very good  Thanks

@bdash Hi ,Sir. I am using a old version realm and want to upgrade it by myself. Now i face this problem , How can i fix the "no viable overloaded '='" issure.？
I have check the commits history carefully but did not find a solution.
Thank you with best wishes.

@LiuDeng, I strongly suggest updating to the most recent version of Realm. Older versions are not compatible with the latest version of Xcode, as the work to make them compatible was made as part of newer versions of Realm. We cannot provide any assistance in attempting to make older versions work in this situation..


Anyway to change UI/tab/tree view font size?

The fonts are so small they're almost unreadable. Is there a way to change this?
I'm on Linux if it's important.

@benogle - nice!

great

:+1

Yes.  You can change it in your style.less folder in ~/.atom.
On Wed, Feb 4, 2015 at 3:48 PM, Liam Newman<EMAIL_ADDRESS>wrote:

:+1
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2530#issuecomment-72965754.

cool

Hooray!

You might want to add .status-bar to that list.

After some tweaking I ended up with this setup:
@font-size: 1rem;
html,
body,
.status-bar,
.tree-view,
.tab-bar .tab,
linter-message {
  font-size: @font-size;
}

Does anyone know how could I make @font-size change along with zoom levels? E.g. ctrl+/-/scroll-up/down. Thanks!

Where can I find the Atom dom elements?  I'd also like to change font size in the search/replace view

View > Developer > Toggle Developer Tools
On Wed, Jan 27, 2016 at 9:22 AM, Dave Ploch<EMAIL_ADDRESS>wrote:

Where can I find the Atom dom elements? I'd also like to change font size
in the search/replace view
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2530#issuecomment-175653739.

Trying to make the font larger in the search-and-replace panel but not
having any luck.  Any ideas?
Dave Ploch
Voice:<PHONE_NUMBER>
[image: Google Plus] https://plus.google.com/+DavePloch/posts [image:
Twitter] http://twitter.com/dwploc [image: LinkedIn]
http://linkedin.com/in/daveploch
On Wed, Jan 27, 2016 at 8:29 AM, Peter Kraus<EMAIL_ADDRESS>wrote:

View > Developer > Toggle Developer Tools
On Wed, Jan 27, 2016 at 9:22 AM, Dave Ploch<EMAIL_ADDRESS>wrote:

Where can I find the Atom dom elements? I'd also like to change font size
in the search/replace view
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2530#issuecomment-175653739.

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/2530#issuecomment-175655906.

@dwploc .tool-panel looks universal

@benogle Thx  it work!

Does anyone know how could I make @font-size change along with zoom levels? E.g. ctrl+/-/scroll-up/down. Thanks!

I second this!!!
Recently I gave VSCode a whirl and it had one absolutely fantastic feature: CMD +/- increased EVERY font size throughout the entire UI.  Tollbar, Folder Tree, Statusbar - everything.  And the exact same font ratio as well.

^- that's a fullscreen shot at 3840x2400!  I blew everything up for a screenshare I did on Friday where some team members said they couldn't see my font.
  Just make a few CMD-+ to blow everything up to enormous size and everyone is happy.
How can we bring this to Atom?

@elektronik2k5 (and others)
We've figured out how to bind this to a shortcut key:
https://github.com/atom/atom/issues/11905#issuecomment-224865625
https://cloud.githubusercontent.com/assets/378023/15927753/5e29d1bc-2e7e-11e6-9d0c-8acb47de6442.gif

I'll addon to @elektronik2k5 to change tree view
html, body, .tree-view, .tooltip, .tab-bar .tab, .find-and-replace .find-meta-container, atom-text-editor[mini], .btn, .status-bar, .list-tree li.list-nested-item > .list-item {   font-size: @font-size; }

This should be shipped with Atom by default, really helps with higher resolution screens.

OK guys, so how do we noobs in 2017 achieve this without having to dig too deep?

I didn't find anything to do it without changing stylesheet...
Btw, this is how you can change it : Edit > Stylesheet...

most of the default themes have their own settings page which will allow you to change the font size. See examples here: https://github.com/atom/atom/issues/13055

What about the menu bar text.
(File Edit View Selections Find Packages Help ...)

@uid89626 I think that is native UI, thus can be changed by system settings.

Thanks a lot @benogle

+1 for a zoom change to change EVERYTHING


[DRAFT] feat: restyle listing table and polish listing card

After
https://github.com/metrotranscom/doorway/assets/10789523/265fbd87-ad73-4666-9f37-1aae077204e4
Before

Notes

fix listing page table

oop sorry, accidentally committed a temp commit -- will squash merge so this should hopefully just be an errant comment


Cleaning up the modules folder

Currently, we are loading all the external modules into the modules folder. There are a few cleanup items that need to happen in order to ensure the system is smooth and as overhead-free as possible:

[ ] Make the folder hidden from GitHub
[ ] Automatically check that the modules are properly loaded (and load them if not)

Closing as it is no longer relevant


jekyll 3.4 support

If I hack the gemspec, v1.0.0 seems to work fine with jekyll 3.4 - is there any willingness to bump the gemspec? Is there a test suite which needs to run?

Whoops, just noticed that this seems to be fixed.


Removed the two deprecated "Mastering Markdown" links

As per #20424
- "[Mastering Markdown](https://guides.github.com/features/mastering-markdown/)"

In both:

About writing and formatting on GitHub
Basic writing and formatting syntax

@Veylkh Thanks for opening an issue and PR! I've made a slight edit to your post to link the two together.
I'll get this triaged for review! ⚡


Reorder HttpsRedirection in spa templates

Missed a few in my last PR #137

@jkotalik,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot


RemovedInNextVersionWarning: legacy encryption_mode is deprecated, use modern instead.   SessionManager.cookies('myverysecretkey'),

#: pipeline
app.pipeline = [
    SessionManager.cookies('myverysecretkey'),
    db.pipe,
    auth.pipe
]

Hi @gi0baro. This is the offending code. What should I do to suppress the warning?

@eclecticlly you need to install Emmett with crypto extras and set the encryption_mode parameter of SessionManager.cookies to modern.
Details available in docs, see:

https://emmett.sh/docs/2.4.x/sessions#storing-sessions-in-cookies
https://emmett.sh/docs/2.4.x/upgrading#version-23


Disallow creation of non-CRS (eg pipeline) in CRS class

From discussion with @snowman2
Currently, you can create a CRS object from eg a proj pipeline:
In [4]: pyproj.CRS("+proj=pipeline +ellps=GRS80 +step +proj=merc +step +proj=axisswap +order=2,1")
Out[4]:
<CRS: +proj=pipeline +ellps=GRS80 +step +proj=merc +step ...>
Name: PROJ-based coordinate operation
Ellipsoid:
- UNDEFINED
Area of Use:
- UNDEFINED
Prime Meridian:
- UNDEFINED
Axis Info:
- UNDEFINED

which does not give you an actual CRS, but generic coordinate transformation. So it is probably a good idea to disallow this in the construction of a CRS object.
For this specific case we could check for proj=pipeline in the string. Or more in general we could check the proj_type and raise an error if it is not one of the CRS types (we could still do the first pipeline check as well to have a better error message for that specific case).

I think just need to check that proj_type == PJ_TYPE_CRS

I think just need to check that proj_type == PJ_TYPE_CRS

Not sure if that is enough, as you have also PJ_TYPE_PROJECTED_CRS etc (don't know how such an equality check works, but I assume it is like an enum, and not aware that PJ_TYPE_PROJECTED_CRS is a subset of PJ_TYPE_CRS) ?
There is also proj_is_crs that can be probably used for this

The proj_is_crs looks perfect. I am glad you found that.

I have a less than optimal implementation in #263.

I am going to close this as the solution is merged into master. Thanks for bringing up the idea!


3 changes

"back" icon and "metrics" icon changed
metrics icon changes on mouseover
compenant name in drilldown menu re-positioned and re-sized

One additional comment, can you please check the spelling of the comments and reference the github issue, in case the commit closes an issue?
Let's use Closes #12 - "Your message"
You can check the commit format here:
https://github.com/inspectIT/inspectit-ocelot/commits/master