I just encountered a SMTLIB problem in string theory that Z3 might have answered inconsistently. When envoking Z3 to solve the problem: with argument smt.string_solver=z3str3 it returns unsat; without any arguments it returns sat.
I also used CVC4 to solve the problem. It returned a solution, which seems to be a valid model as I checked it by manually replacing the variable assignments into the problem.
Since I'm trying to do a research using Z3, I would like to know if this is a known behavior of Z3. Thanks to anyone that could help! :)
Edit: I was using Z3 4.7.1 on WSL Ubuntu 16.04.
I'd say that getting unsat or sat, depending on Z3's configuration, sounds like a bug to me. Check the Z3 issue tracker for issues that describe a similar behaviour, and if nothing pops up, file an issue there. Ideally with a minimal example to reproduce the problem with, your current one is rather long.
Related
I have seen both of these written down in Colab Notebooks, Can someone please explain the difference between them? Thanks
In spaCy v2, it was possible to use shorthand to refer to a model in some circumstances, so "en" could be the same as "en_core_web_sm".
The way this worked internally kind of relied on symlinks, which added file system state and caused issues on Windows. This caused troubleshooting problems and confusion, so it was decided the convenience of the short names wasn't worth it, and there are no short names in v3.
So if you see code using spacy.load("en") it's using v2. There's no meaningful difference in how it works though.
I'm a new python programmer. Currently, we are switching from python2 to python3, and we found out all the python script generated by grpc have code like this.
import dataPlatform_pb2 as dataPlatform__pb2
However, python3 do not support this type of relative path import. I need to manually change it to
from . import dataPlatform_pb as dataPlatform__pb2
Is there any better solution for this problem, it seems a bad practice to changing auto generated code all the time.
I don't think there's anything different that you should be doing at this time. We're working on a fix for the issue but it's likely several weeks from being released. In the meantime I've filed this issue to track adding test coverage representative of your specific use case.
I apologize that we don't have a better answer right now. An easy and practical workaround for the nonce might be to nest your code in a package (directory).
According to the occurrence of questions about 'AutoMapper Migraton from static API' lately and the fact I was Exploring Christos Sakell blog 'Building Single Page Applications using Web API and AngularJS', I also came across some obsolete warnings.
/***********************************************************************************
* AutoMapper.Mapper.CreateMap()' is obsolete: 'Dynamically creating maps will be removed in version 5.0.
* Use a MapperConfiguration instance and store statically as needed, or Mapper.Initialize.
* Use CreateMapper to create a mapper instance.
***********************************************************************************/
Completely ignorant of recent changes of AutoMapper (I using this mapping tool for the very first time) I was trying to get rid of those obsolete messages. Searching around I came across two possible solutions:
1) http://quabr.com/36398318/automapper-mapper-createmaptsource-tdestination-is-obsolete , and
2) http://davecallan.com/automapper-4-2-example/#comment-8914
These hints seemed to be pretty straightforward. It turned out tweaking the *MappingProfile classes weren't that difficult, but what to do on several controllers? That was a complete different piece of cake. I got completely lost. I ran in all kind of strange errors not knowing or having a clue what to do. Even the just mentioned blogs weren’t that explanative. More or less, I got the feeling they were keeping the puzzle a live (I'm kidding).
So the question was: how to solve the troublesome mapping from the controller to the *MappingProfile class. Luckily, I found a possible solution, so please tackle it...
I do like puzzling and buzzing around the net, I finally found a combination of hints, and that's what I want to share with you.
The solution for this is a combination of tweaks.
First of all, have a look at page 'Migrating from static API' (https://github.com/AutoMapper/AutoMapper/wiki/Migrating-from-static-API).
Notice the second block right below ‘In 4.2.x and later …’ that’s what is needed on several controllers. Dave Callan just gave a part of the clue. He just forgot a part of the solution. So I asked him to add the missing part to his solution as well.
So, implementing the hint on the 'Migrating from static API' page in combination with the suggestion of Dave Callan (http://davecallan.com/automapper-4-2-example/#comment-8919) block 1: Instantiating a new MapperConfiguration(...) in *MappingProfile class(es), you can get rid of those obsolete warnings: On every cycle proper mapping.
At least, I got rid of those warnings.
What will happend in the nearer future with AutoMapper, hopefully those guys in Austin TX will make proper decisions on this matter.
I also testing the code (block 2 of 'Migration from static API') with the suggestion on Quabr (instead of instantiating a new MapperConfiguration, they suggest to call the Initialize method of the current Mapper). This combination gave my errors like ‘index outside matrix borders’.
Apparently on each cycle the mapping lists are not renewed. This combination of code tweaks resulted (to me) in a ‘no go’. Perhaps others, do not agree with me, fine, at least that’s what I noticed.
My only goal is to help other members who are facing comparable trouble.
I'm pleased to share my solution. Have fun
sorry for the nebulous question, but has anyone observed buggy behaviors
with Data.HashMap.Strict from unordered-containers-0.2.3.0 on GHC 7.6.3?
In particular, there are Maps which clearly contain a key k but lookup
fails (returns Nothing). (I know the key is in the Map because printing
out the results of toList shows the key in the output.
I've seen this across two different code bases now. Does anyone know if this
is a known issue with 0.2.3.0 ? Perhaps I should upgrade?
Otherwise, I will put in the time to find a minimal test that shows the glitch.
(Also, if I should ask this elsewhere, please let me know...)
Thanks!
Ranjit.
It looks like #66.
You can try building HEAD with -f-sse2 and see if it helps.
(Note that it doesn't have a proper fix yet, only a workaround.)
If you have simple code to show the problem, please add it to the issue.
I tried the following code which works fine in the Windows CLR:
System.Diagnostics.Process.GetCurrentProcess().Threads.Count
... resulting in something > 0.
However under Mono on OS X or Linux it always results in 0
Is this a bug in Mono or do I need another approach because of platform differences?
Going straight to the source, it appears that it's not exactly a bug, but is instead completely unimplemented (note the [MonoTODO] attribute on this method).
Your best course of action would be to open a bug against Mono on Xamarin's bug tracker. It's probably not terribly hard to build this, and it seems like someone on the project may be ashamed enough that this isn't done that they'll fix it quickly.
If you need this to work in the meanwhile, I've got a branch on github that implements a fix for this. I'll work with the Mono folks to see whether/how they want to integrate it.
Update: It has been pulled into the master branch of Mono.